build(log-viewer-webui-client): Switch from Webpack to Vite for bundling; Convert the codebase to TypeScript. #645
Conversation
|
Warning Rate limit exceeded@junhaoliao has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 19 minutes and 4 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (2)
WalkthroughThis pull request represents a comprehensive migration of the log viewer web UI from JavaScript and Webpack to TypeScript and Vite. The changes involve updating the project's build configuration, dependency management, and source code structure. Key modifications include transitioning to TypeScript, replacing Webpack with Vite, updating React and related library dependencies, and enhancing type safety across the application's components. Changes
Sequence DiagramsequenceDiagram
participant Client as React App
participant API as Query API
participant Backend as Log Backend
Client->>API: submitExtractStreamJob()
API->>Backend: POST /query/extract-stream
Backend-->>API: Return stream response
API-->>Client: Resolve with ExtractStreamResp
Possibly Related PRs
Suggested Reviewers
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 (
|
![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 (4)
components/log-viewer-webui/client/src/index.tsx (1)
9-10: Consider gracefully handling potential null references.While the non-null assertion operator (
!) informs TypeScript that the element will never be null, it could still lead to runtime errors if the element does not actually exist. It might be safer to throw an error or provide a fallback to handle this scenario more robustly.Below is a sample approach:
-const root = createRoot(document.getElementById("root")!); +const rootElement = document.getElementById("root"); +if (false == rootElement) { + throw new Error("Root element not found in DOM"); +} +const root = createRoot(rootElement);components/log-viewer-webui/client/src/App.tsx (1)
10-10: Confirm JSDoc return annotation.Removing the explicit return type is often fine in TypeScript since return types can be inferred. However, please ensure that your documentation accurately reflects the function’s intended return structure.
components/log-viewer-webui/client/src/api/query.ts (1)
29-44: Enhance error handling and request cancellation.While
submitExtractStreamJobis straightforward, consider adding optional request cancellation (via Axios.cancelToken) or error handling to avoid unhandled promise rejections if the server or network fails.components/log-viewer-webui/client/src/ui/QueryStatus.tsx (1)
29-29: Document return values more explicitly.
Please clarify the returned type or structure to help future readers understand the component’s outcome.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
components/log-viewer-webui/client/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (12)
components/log-viewer-webui/client/package.json(2 hunks)components/log-viewer-webui/client/src/App.tsx(1 hunks)components/log-viewer-webui/client/src/api/query.js(0 hunks)components/log-viewer-webui/client/src/api/query.ts(1 hunks)components/log-viewer-webui/client/src/index.tsx(1 hunks)components/log-viewer-webui/client/src/typings/common.ts(1 hunks)components/log-viewer-webui/client/src/typings/query.js(0 hunks)components/log-viewer-webui/client/src/typings/query.ts(1 hunks)components/log-viewer-webui/client/src/ui/Loading.tsx(3 hunks)components/log-viewer-webui/client/src/ui/QueryStatus.tsx(3 hunks)components/log-viewer-webui/client/tsconfig.json(1 hunks)components/log-viewer-webui/client/webpack.config.js(4 hunks)
💤 Files with no reviewable changes (2)
- components/log-viewer-webui/client/src/api/query.js
- components/log-viewer-webui/client/src/typings/query.js
✅ Files skipped from review due to trivial changes (1)
- components/log-viewer-webui/client/src/typings/common.ts
🧰 Additional context used
📓 Path-based instructions (7)
components/log-viewer-webui/client/src/index.tsx (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
components/log-viewer-webui/client/webpack.config.js (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
components/log-viewer-webui/client/src/App.tsx (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
components/log-viewer-webui/client/src/api/query.ts (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
components/log-viewer-webui/client/src/ui/Loading.tsx (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
components/log-viewer-webui/client/src/typings/query.ts (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
components/log-viewer-webui/client/src/ui/QueryStatus.tsx (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
🔇 Additional comments (48)
components/log-viewer-webui/client/src/App.tsx (2)
1-1: Confirm updated import path for CssVarsProvider.
The new import path @mui/joy is correct for the current version of MUI Joy. Please confirm that this is aligned with your package.json dependencies.
3-4: Ensure consistent usage of TypeScript imports.
Dropping the file extensions is appropriate given your tsconfig settings. Double-check that all references to these imports have been updated accordingly in the rest of the project.
components/log-viewer-webui/client/src/api/query.ts (4)
1-4: Validate Axios import for TypeScript usage.
Your imports from Axios are compatible with TypeScript. Ensure that your tsconfig includes the necessary type definitions for Axios to avoid runtime or type definition issues.
6-16: Enum usage for QUERY_JOB_TYPE.
Leveraging QUERY_JOB_TYPE in TypeScript helps prevent invalid job-type values. Confirm that calling code passes valid enum members.
9-16: Check interface fields align with backend schema.
The fields in ExtractStreamResp appear to match typical streaming extraction responses. Confirm with backend docs that the field names (begin_msg_ix, is_last_chunk, etc.) remain stable or forward-compatible.
46-46: Export structure is consistent with TypeScript norms.
Exporting submitExtractStreamJob from this file provides a clean API surface for your data-fetching logic. Good work keeping it readable and modular.
components/log-viewer-webui/client/src/typings/query.ts (6)
1-5: Numeric enum usage is valid.
Using numeric enums for QUERY_LOADING_STATE is fine. If you ever need more explicit debugging or logging, consider string enums or an equivalent mapping for greater clarity.
7-12: Filtering enum values to numeric types.
The approach of filtering out string enum keys from the Object.values(QUERY_LOADING_STATE) array is efficient. This logic is correct for numeric enums.
14-18: QUERY_JOB_TYPE validity.
Ensure these job types don’t overlap with existing or potential future ones. Numeric enums can inadvertently overlap if not carefully tracked, so consider a stable numbering scheme.
20-23: Interface definitions match usage.
QueryLoadingStateDescription is clearly structured. Nicely done on using a separate interface for clarity.
28-43: Providing descriptive labels is helpful.
QUERY_LOADING_STATE_DESCRIPTIONS nicely documents each enum’s purpose. This improves maintainability. Great usage of Object.freeze for immutability.
45-50: Exports are well-organized.
All relevant symbols are exported for external usage. This aligns with a neat and modular TypeScript codebase.
components/log-viewer-webui/client/webpack.config.js (7)
36-36: Entry point switched to TypeScript index.
Switching from index.jsx to index.tsx is consistent with the migration to TypeScript. Verify that your scripts and references in package.json also reflect this change.
37-39: Mode configuration is correct.
Using environment-based modes is standard practice. Ensure that your build process sets NODE_ENV correctly.
43-43: Refined test pattern for TS/TSX.
Updating the regex ensures proper handling of .ts/.tsx files. Confirm that .js or .jsx is no longer needed if you’ve fully migrated.
56-56: Added TypeScript Babel preset.
Including @babel/preset-typescript is crucial for transpiling TypeScript. Looks good.
73-87: SplitChunks for better performance.
Your splitChunks configuration ensures proper vendor chunking to boost caching and reduce bundle sizes. Good practice.
103-104: Extended resolve with TS/TSX.
Adding .ts/.tsx to resolve.extensions is correct for a TypeScript codebase. Confirm that any .jsx references are not needed.
109-109: Exporting config object.
Exporting the Webpack config object is a clean approach that simplifies usage. Nice move.
components/log-viewer-webui/client/src/ui/QueryStatus.tsx (8)
7-7: Implementation of isAxiosError is beneficial.
This import helps refine error handling for Axios requests, ensuring more accurate detection of Axios-related issues.
9-15: Imports for new type definitions appear streamlined.
Bringing in submitExtractStreamJob, Nullable, and the QUERY_LOADING_STATE constants from separate files fosters modularity and clarity.
32-35: Adoption of strong state typing looks solid.
Using generic types for useState clarifies the permissible values, reducing unintended usage.
57-57: Confirm logical intention of false === streamType in EXTRACT_JOB_TYPE.
While this meets the style preference for false == expression, the operator precedence may be confusing. Consider adding parentheses or using an explicit check (e.g. false == (streamType in EXTRACT_JOB_TYPE)) to convey your intent more clearly.
64-65: Sanitizing user input is prudent.
Using Number() ensures logEventIdx is converted to a numeric type. This helps avoid injection issues and fosters type consistency.
70-72: Updating state on job submission is accurate.
Transitioning to the WAITING state upon submission clarifies the user that a process is in progress.
76-79: Smooth transition to LOADING with correct offset usage.
Calculating innerLogEventNum ensures the log event index aligns with the server’s base offset. Redirection is correct, and usage of window.location.href is consistent with the new approach.
82-84: Comprehensive error handling.
Distinguishing Axios errors from general exceptions helps provide more accurate feedback to the user. Good approach.
components/log-viewer-webui/client/src/ui/Loading.tsx (9)
1-1: Neat import of React.
Explicitly importing React ensures consistent usage of JSX transformations under the TypeScript environment.
12-12: DefaultColorPalette usage is consistent.
Allows for a typed palette configuration, reducing the risk of undefined colour usage.
14-14: Nullable type fosters clarity for optional fields.
This approach clearly conveys which properties can be null, enhancing reliability.
16-19: Use of enumerated states simplifies logic.
Referencing QUERY_LOADING_STATE and related constants reduces magic strings.
24-31: LoadingStepProps interface definitions are straightforward.
These type annotations provide clarity for each required prop, reducing guesswork for future contributors.
49-50: Conditional colour assignment is intuitive.
The code clearly differentiates active and error states, enhancing readability.
84-87: LoadingProps interface is well-defined.
Specifying these types ensures consistent usage of currentState and errorMsg throughout the component.
97-100: Structured destructuring of props.
Explicitly typed parameters help TypeScript detect possible misuses at compile time.
101-103: Building steps array based on states improves maintainability.
Looping through known state values in QUERY_LOADING_STATE_VALUES helps ensure all defined states are handled.
components/log-viewer-webui/client/package.json (4)
5-5: Switching main entry to src/index.tsx is appropriate.
Reflects the recent TypeScript migration, ensuring the build references the correct entry point.
7-7: Upgrading the build script.
Using --config-node-env production aligns with the updated webpack CLI usage, which resolves deprecation in older versions.
16-35: Dependency updates facilitate TypeScript support.
Including @babel/preset-typescript plus updated Babel/webpack dependencies is crucial for the TypeScript build pipeline.
36-86: Dependencies reorganized for clarity and usage.
Promoting relevant libraries (e.g. react, axios) into dependencies ensures they are accessible in production. ESlint configuration is robust, with coverage for TypeScript files.
components/log-viewer-webui/client/tsconfig.json (8)
1-7: Inclusion/exclusion paths are clearly defined.
This separation ensures extraneous files such as node_modules do not affect compilation time or produce unnecessary errors.
8-35: Targeting ES2022 with DOM library is appropriate.
Allows usage of next-gen JavaScript features while supporting browser-based functionalities.
39-44: ESNext module system with bundler resolution is modern.
Harmonizes well with contemporary bundlers and ensures top-level await or other ESNext features can be leveraged.
50-58: Permitting JSON imports is beneficial.
This functionality can consolidate certain config or data definitions directly into the TypeScript code.
63-67: allowJs and checkJs help unify JS and TS.
This configuration is valuable during transitional phases, ensuring JS still gets type-checked where possible.
74-83: sourceMap and noEmit are well-chosen.
Emitting source maps aids debugging, while noEmit clarifies that compiled output is handled by the bundler.
100-106: Enabling isolated modules and ES module interop is standard.
Helps ensure each file is self-sufficient during transpilation, plus broadens import compatibility for third-party modules.
108-143: Strict type checking is thoroughly configured.
Enabling strict mode and measures such as noImplicitAny, strictNullChecks, and noUnusedLocals fosters maintainable, predictable code.
There was a problem hiding this comment.
Everything was taken from https://github.com/y-scope/yscope-log-viewer/blob/7e6073f7c996f55721f41088ac2d8506085981ad/tsconfig.json except noted below.
There was a problem hiding this comment.
This comment no longer applies.
The linting rules are indeed ported to tsconfig.node.ts and tsconfig.app.ts though.
| @@ -0,0 +1,152 @@ | |||
| { | |||
| "include": [ | |||
| "src", | |||
There was a problem hiding this comment.
compared to the one in yscope-log-viewer, removed
"jest.config.ts",
"test",
| /* Specify a set of bundled library declaration files that describe the target runtime environment. */ | ||
| "lib": [ | ||
| "ES2022", | ||
| "DOM", |
There was a problem hiding this comment.
compared to the one in yscope-log-viewer, removed
"DOM.Iterable",
"WebWorker",
| ], | ||
| }, | ||
| }; | ||
|
|
||
| export default () => { |
There was a problem hiding this comment.
@kirkrodrigues I don't recall if we discussed this for #468 - Did we have to export a function and change the config.mode dynamically? Can we simply define the mode in the above config object and return the object directly?
There was a problem hiding this comment.
Yeah, that's my understanding based on this: https://webpack.js.org/configuration/configuration-types/#exporting-a-function
I think the old code was wrong since it should've been using the env argument to determine whether it was prod/dev rather than isProduction. Based on a glance at this, I guess we shouldn't be using process.env.NODE_ENV in a webpack config.
There was a problem hiding this comment.
Gotcha. Let me defer this after investigating the viability of turning the app into a Vite-React app.
There was a problem hiding this comment.
The attempt to migrate to Vite was effortless and they provide all what we need with very simple configuration interfaces. I think we can stick with Vite in this project.
| @@ -33,11 +33,14 @@ const config = { | |||
| devtool: isProduction ? | |||
| "source-map" : | |||
| "eval-source-map", | |||
| entry: path.resolve(dirname, "src", "index.jsx"), | |||
| entry: path.resolve(dirname, "src", "index.tsx"), | |||
| mode: isProduction ? | |||
There was a problem hiding this comment.
Note this was moved from the default-exported function.
|
Alternatively, shall we look into turning this into a Vite-React app? That way we don't have to manage the build configs on our own with webpack. |
We could, I guess. |
junhaoliao
changed the title
junhaoliao
changed the title
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (7)
components/log-viewer-webui/client/tsconfig.node.json (2)
3-7: Consider relocating tsBuildInfo and reviewing skipLibCheck settingTwo suggestions for improvement:
- Consider moving
tsBuildInfoFileoutside ofnode_modulesto avoid CI/CD caching issues. A better location would be.ts-cacheor similar.- The
skipLibCheck: truesetting might hide type issues in dependencies. Consider setting it tofalseif build time permits.- "tsBuildInfoFile": "./node_modules/.tmp/tsconfig.node.tsbuildinfo", + "tsBuildInfoFile": "./.ts-cache/tsconfig.node.tsbuildinfo",
16-21: Consider enabling additional strict checksThe current strict checks are good, but consider enabling these additional TypeScript checks for better type safety:
noImplicitReturns: Ensure all code paths return a valueexactOptionalPropertyTypes: More precise optional property typesnoPropertyAccessFromIndexSignature: Prevent typos in property access"strict": true, "noUnusedLocals": true, "noUnusedParameters": true, "noFallthroughCasesInSwitch": true, - "noUncheckedSideEffectImports": true + "noUncheckedSideEffectImports": true, + "noImplicitReturns": true, + "exactOptionalPropertyTypes": true, + "noPropertyAccessFromIndexSignature": true🧰 Tools
🪛 Biome (1.9.4)
[error] 16-16: JSON standard does not allow comments.
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 17-17: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 17-17: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 17-17: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 18-18: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 18-18: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 18-18: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 18-18: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
components/log-viewer-webui/client/tsconfig.app.json (2)
18-23: Consider additional type-checking optionsThe current linting configuration is good, but could be enhanced with these additional checks:
{ "compilerOptions": { /* Linting */ "strict": true, "noUnusedLocals": true, "noUnusedParameters": true, "noFallthroughCasesInSwitch": true, - "noUncheckedSideEffectImports": true + "noUncheckedSideEffectImports": true, + "noImplicitReturns": true, + "exactOptionalPropertyTypes": true, + "noPropertyAccessFromIndexSignature": true } }🧰 Tools
🪛 Biome (1.9.4)
[error] 18-18: JSON standard does not allow comments.
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 19-19: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 20-20: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 21-21: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 22-22: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 22-22: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 22-22: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 22-22: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 23-23: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 23-23: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 23-23: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
25-25: Consider more specific include/exclude pathsThe current configuration includes all files under
src. Consider adding anexcludearray to filter out test files and other non-app code:{ "compilerOptions": { // ... existing options ... }, - "include": ["src"] + "include": ["src"], + "exclude": ["src/**/*.test.ts", "src/**/*.test.tsx", "src/**/*.spec.ts", "src/**/*.spec.tsx"] }🧰 Tools
🪛 Biome (1.9.4)
[error] 25-25: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 25-25: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 25-25: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
[error] 25-26: End of file expected
Use an array for a sequence of values:
[1, 2](parse)
components/log-viewer-webui/client/vite.config.ts (1)
1-18: Consider environment variables for development and production differences.Currently, the server proxy is hard-coded to
http://localhost:3000/query. You may want to employ environment variables (e.g.,process.env.NODE_ENVfor dev or production) or a.envfile to manage different URLs. This would enhance deploy-time flexibility.components/log-viewer-webui/client/package.json (2)
5-5: Use a more descriptive entry name if desired.While
"main": "src/main.tsx"is valid, you could consider using a more descriptive name to indicate the application’s entry point. This is purely a stylistic choice that might help distinguish from other modules.
15-22: Document newly introduced dependencies.The new dependencies (
@emotion/*,axios, etc.) should be noted in the project’s documentation to inform future maintainers of their usage. This is especially important when adopting UI libraries like MUI Joy.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
components/log-viewer-webui/client/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (10)
Taskfile.yml(2 hunks)components/log-viewer-webui/client/index.html(1 hunks)components/log-viewer-webui/client/package.json(1 hunks)components/log-viewer-webui/client/src/main.tsx(1 hunks)components/log-viewer-webui/client/src/vite-env.d.ts(1 hunks)components/log-viewer-webui/client/tsconfig.app.json(1 hunks)components/log-viewer-webui/client/tsconfig.json(1 hunks)components/log-viewer-webui/client/tsconfig.node.json(1 hunks)components/log-viewer-webui/client/vite.config.ts(1 hunks)components/log-viewer-webui/client/webpack.config.js(0 hunks)
💤 Files with no reviewable changes (1)
- components/log-viewer-webui/client/webpack.config.js
✅ Files skipped from review due to trivial changes (1)
- components/log-viewer-webui/client/src/vite-env.d.ts
🚧 Files skipped from review as they are similar to previous changes (1)
- components/log-viewer-webui/client/tsconfig.json
🧰 Additional context used
📓 Path-based instructions (2)
components/log-viewer-webui/client/vite.config.ts (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
components/log-viewer-webui/client/src/main.tsx (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
🪛 Biome (1.9.4)
components/log-viewer-webui/client/tsconfig.node.json
[error] 9-9: JSON standard does not allow comments.
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: JSON standard does not allow comments.
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 17-17: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
components/log-viewer-webui/client/tsconfig.app.json
[error] 10-10: JSON standard does not allow comments.
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-18: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 18-18: JSON standard does not allow comments.
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 19-19: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 20-20: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 21-21: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 22-22: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 24-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-25: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 25-26: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
🔇 Additional comments (9)
components/log-viewer-webui/client/tsconfig.node.json (2)
9-14: Bundler configuration is well-suited for Vite
The bundler settings are appropriately configured for a Vite-based TypeScript project. The combination of moduleResolution: "bundler" with allowImportingTsExtensions and isolatedModules ensures compatibility with Vite's development and build processes.
🧰 Tools
🪛 Biome (1.9.4)
[error] 9-9: JSON standard does not allow comments.
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 10-10: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
23-23: Include pattern is appropriate
The include pattern correctly targets only the Vite configuration file, which is appropriate for a Node-specific TypeScript configuration.
🧰 Tools
🪛 Biome (1.9.4)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-23: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 23-24: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
components/log-viewer-webui/client/tsconfig.app.json (2)
10-16: LGTM! Bundler configuration is well-suited for Vite
The bundler mode settings are appropriately configured for a Vite-React application, with proper module resolution and JSX handling.
🧰 Tools
🪛 Biome (1.9.4)
[error] 10-10: JSON standard does not allow comments.
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 11-11: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 12-12: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 13-13: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 14-14: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 15-15: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
[error] 16-16: End of file expected
Use an array for a sequence of values: [1, 2]
(parse)
3-8: Consider the implications of skipLibCheck
The skipLibCheck option is enabled, which skips type-checking of declaration files. While this speeds up compilation, it might hide type errors from dependencies.
Run this script to check if any declaration files have known issues:
✅ Verification successful
skipLibCheck is appropriate for this configuration
Based on the analysis of the project structure and dependencies:
- The project has minimal TypeScript declaration files (only vite-env.d.ts)
- Uses modern dependencies with well-maintained type definitions
- Is a Vite-based React application with TypeScript configuration
- Has proper ESLint configuration for type checking
The skipLibCheck setting is justified here as:
- It speeds up the build process
- The project relies on well-tested npm packages
- Type checking is still performed on the project's source code
- The development setup includes ESLint for additional type safety
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for potential type issues in declaration files
# Look for .d.ts files with @ts-ignore or @ts-nocheck
rg -t ts "(@ts-ignore|@ts-nocheck)" --glob "*.d.ts"
Length of output: 53
Script:
#!/bin/bash
# Let's check for declaration files first to understand the scope
fd "\.d\.ts$"
# Also check package.json to understand dependencies that might need type checking
fd "package.json$" --exec cat {}
Length of output: 5294
components/log-viewer-webui/client/src/main.tsx (1)
9-10: Acknowledge use of non-null assertion.
The non-null assertion operator here, although acceptable, may hide potential null reference errors. An alternative approach could include a conditional check for the element’s existence, or an optional chaining with a fallback. Evaluate whether you want to rely on a strict assertion or implement a more defensive pattern.
components/log-viewer-webui/client/index.html (1)
1-18: Good choice of updated metadata and script handling.
The newly introduced script tag for TypeScript is properly defined, and the updated meta tags consistently reflect best practices for responsive design. This is a clear step towards a well-structured client application.
components/log-viewer-webui/client/package.json (2)
7-10: Confirm linting best practices.
With "lint:check": "eslint" and "lint:fix": "eslint --fix", ensure that the correct lint configurations (including TypeScript rules) are loaded. Otherwise, some TypeScript-specific issues may be overlooked.
24-29: Ensure TypeScript configuration is consistent.
You are referencing "typescript": "~5.6.2". Confirm that your tsconfig files align with the intended TS version. Also, maintain consistent TS practices across your devDependencies and build scripts.
Taskfile.yml (1)
227-232: Source files properly updated for TypeScript migration!
The changes correctly reflect the transition to TypeScript by:
- Adding TypeScript configuration files
- Including
.tsand.tsxsource files - Adding
index.htmlfor the client entry point
Taskfile.yml
Outdated
| - |- | ||
| cd "client" | ||
| PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \ | ||
| --outDir "{{.OUTPUT_DIR}}/client" | ||
| - |- | ||
| cd "yscope-log-viewer" | ||
| PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \ | ||
| --output-path "{{.OUTPUT_DIR}}/yscope-log-viewer" |
There was a problem hiding this comment.
Fix indentation in build commands
The build commands have inconsistent indentation which could cause YAML parsing issues.
Apply this diff to fix the indentation:
- |-
cd "client"
PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \
- --outDir "{{.OUTPUT_DIR}}/client"
+ --outDir "{{.OUTPUT_DIR}}/client"
- |-
cd "yscope-log-viewer"
PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \
- --output-path "{{.OUTPUT_DIR}}/yscope-log-viewer"
+ --output-path "{{.OUTPUT_DIR}}/yscope-log-viewer"📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - |- | |
| cd "client" | |
| PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \ | |
| --outDir "{{.OUTPUT_DIR}}/client" | |
| - |- | |
| cd "yscope-log-viewer" | |
| PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \ | |
| --output-path "{{.OUTPUT_DIR}}/yscope-log-viewer" | |
| - |- | |
| cd "client" | |
| PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \ | |
| --outDir "{{.OUTPUT_DIR}}/client" | |
| - |- | |
| cd "yscope-log-viewer" | |
| PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \ | |
| --output-path "{{.OUTPUT_DIR}}/yscope-log-viewer" |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (8)
Taskfile.yml (1)
250-257: Add comments to clarify the build tools in use.While the build commands are well-structured, it would be helpful to add comments indicating that these are Vite and webpack builds respectively.
Apply this diff to improve clarity:
- |- cd "client" + # Build the client using Vite PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \ --outDir "{{.OUTPUT_DIR}}/client" - |- cd "yscope-log-viewer" + # Build the log viewer using webpack PATH="{{.G_NODEJS_22_BIN_DIR}}":$PATH npm run build -- \ --output-path "{{.OUTPUT_DIR}}/yscope-log-viewer"components/log-viewer-webui/client/src/api/query.ts (2)
9-16: Consider adding JSDoc comments to interface fields.While the interface is well-structured, adding documentation for each field would improve code maintainability and make the purpose of each field clearer to other developers.
interface ExtractStreamResp { + /** Unique identifier for the extraction job */ _id: string; + /** Starting message index in the stream */ begin_msg_ix: number; + /** Ending message index in the stream */ end_msg_ix: number; + /** Indicates if this is the final chunk of the stream */ is_last_chunk: boolean; + /** File path to the extracted stream */ path: string; + /** Identifier of the stream being extracted */ stream_id: string; }
19-44: Consider enhancing error handling and configuration.Two suggestions for improvement:
- Add explicit error handling with typed error responses
- Consider making the API endpoint URL configurable
Example implementation:
interface ExtractStreamError { code: string; message: string; } const API_ENDPOINTS = { extractStream: '/query/extract-stream' } as const; const submitExtractStreamJob = async ( extractJobType: QUERY_JOB_TYPE, streamId: string, logEventIdx: number, onUploadProgress: (progressEvent: AxiosProgressEvent) => void, ): Promise<AxiosResponse<ExtractStreamResp>> => { try { return await axios.post( API_ENDPOINTS.extractStream, { extractJobType, streamId, logEventIdx, }, {onUploadProgress} ); } catch (error) { if (axios.isAxiosError<ExtractStreamError>(error)) { // Handle specific API errors throw new Error(`Extract stream failed: ${error.response?.data.message}`); } throw error; } };components/log-viewer-webui/client/src/ui/Loading.tsx (5)
24-30: LGTM! Well-structured TypeScript interfaces.The type definitions are clear and comprehensive. The use of the
Nullabletype forerrorMsgshows good type reuse practices.Consider making the props interfaces
readonlyto prevent accidental mutations:-interface LoadingStepProps { +interface LoadingStepProps { + readonly description: string; + readonly isActive: boolean; + readonly isError: boolean; + readonly label: string; + readonly stepIndicatorText: number | string; } -interface LoadingProps { +interface LoadingProps { + readonly currentState: QUERY_LOADING_STATE; + readonly errorMsg: Nullable<string>; }Also applies to: 84-87
33-41: Enhance JSDoc documentation.The JSDoc comments could be more descriptive and include return type information.
Consider updating the documentation:
/** - * Renders a step with a label and description. + * Renders a loading step with a label, description, and customizable indicator. * * @param props * @param props.description - Description text for the loading step * @param props.isActive - Whether this step is currently active * @param props.isError - Whether this step is in an error state * @param props.label - Label text for the loading step * @param props.stepIndicatorText - Text or number to display in the step indicator - * @return + * @returns {JSX.Element} A styled step component */
Line range hint
50-57: Simplify color logic using ternary operator.The color logic can be more concise while maintaining readability.
Consider this refactor:
- let color: DefaultColorPalette = isActive ? - "primary" : - "neutral"; - - if (isError) { - color = "danger"; - } + const color: DefaultColorPalette = isError ? "danger" : (isActive ? "primary" : "neutral");
131-134: Use TypeScript nullish checks.Replace explicit null comparisons with TypeScript's nullish checking operator for better idiomatic TypeScript code.
Consider this refactor:
- determinate={null !== errorMsg} - color={null === errorMsg ? + determinate={!!errorMsg} + color={errorMsg === null ?
101-102: Optimize steps array generation with useMemo.The steps array is recreated on every render. Consider memoizing it to improve performance.
Consider this refactor:
- const steps: React.ReactNode[] = []; - QUERY_LOADING_STATE_VALUES.forEach((state) => { + const steps = React.useMemo(() => { + const stepsArray: React.ReactNode[] = []; + QUERY_LOADING_STATE_VALUES.forEach((state) => {Then wrap the entire steps generation logic in the useMemo hook with appropriate dependencies:
}, [currentState, errorMsg]);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
components/log-viewer-webui/client/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (7)
Taskfile.yml(2 hunks)components/log-viewer-webui/client/eslint.config.mjs(1 hunks)components/log-viewer-webui/client/src/api/query.ts(1 hunks)components/log-viewer-webui/client/src/typings/LOCAL_STORAGE_KEY.ts(1 hunks)components/log-viewer-webui/client/src/typings/query.ts(1 hunks)components/log-viewer-webui/client/src/ui/Loading.tsx(4 hunks)components/log-viewer-webui/client/vite.config.ts(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- components/log-viewer-webui/client/src/typings/LOCAL_STORAGE_KEY.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- components/log-viewer-webui/client/vite.config.ts
- components/log-viewer-webui/client/src/typings/query.ts
🧰 Additional context used
📓 Path-based instructions (2)
components/log-viewer-webui/client/src/api/query.ts (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
components/log-viewer-webui/client/src/ui/Loading.tsx (1)
Pattern **/*.{cpp,hpp,java,js,jsx,ts,tsx}: - Prefer false == <expression> rather than !<expression>.
🔇 Additional comments (9)
Taskfile.yml (1)
227-232: LGTM! Source file patterns updated for TypeScript.
The changes correctly reflect the migration from JSX to TypeScript by:
- Adding TypeScript configuration files
- Including the Vite entry point (index.html)
- Updating source patterns from
.jsxto.tsand.tsx
components/log-viewer-webui/client/src/api/query.ts (2)
1-7: LGTM! Well-structured imports.
The imports are properly organized with specific type imports from axios and a clear separation between external and local imports.
46-46: LGTM! Clear and explicit export.
The named export is appropriate and follows TypeScript best practices.
components/log-viewer-webui/client/eslint.config.mjs (6)
1-4: Configuration imports look consistent and aligned with best practices.
Importing the CommonConfig, ReactConfigArray, StylisticConfigArray, and TsConfigArray modules in this manner is idiomatic and helps ensure that these configurations remain modular and comprehendible.
7-13: Folder ignore patterns are appropriate.
Excluding the dist/ and node_modules/ folders from linting is a standard practice, preventing unnecessary checks on distribution builds and third-party packages.
14-23: Effective integration of TsConfigArray.
Aggregating multiple TypeScript configurations using a map function keeps your ESLint rules DRY while extending coverage to both .ts and .tsx files. This approach aligns well with TypeScript-based React projects.
24-34: Targeted overrides for different TypeScript configurations.
Using createTsConfigOverride to specify distinct tsconfig.app.json versus tsconfig.node.json is beneficial for large repositories with diverse environments, as it offers clarity and maintainability. These overrides help ensure TypeScript is correctly configured for client (app) and build-tool (node) code.
35-37: Stylistic and React rules are seamlessly merged.
Adding StylisticConfigArray and ReactConfigArray ensures consistent style enforcement and React-specific linting, promoting maintainable and uniform code across the project.
40-40: Export statement follows modern ECMAScript standards.
Exporting EslintConfig as the default helps with discoverability and import clarity in other parts of the build setup. No issues identified.
| <title>Log Viewer Web UI</title> | ||
| <meta charset="utf-8"/> | ||
| <meta name="description" content="YScope Log Viewer Web UI"> | ||
| <meta name="viewport" content="width=device-width, initial-scale=1.0"/> |
There was a problem hiding this comment.
This is copied from the Vite react-ts tempalte.
| </head> | ||
| <body> | ||
| <div id="root"></div> | ||
| <script type="module" src="/src/main.tsx"></script> |
There was a problem hiding this comment.
This is copied from the Vite react-ts tempalte.
| <!doctype html> | ||
| <html lang="en"> | ||
| <head> | ||
| <title>Log Viewer Web UI</title> |
| <head> | ||
| <title>Log Viewer Web UI</title> | ||
| <meta charset="utf-8"/> | ||
| <meta name="description" content="YScope Log Viewer Web UI"> |
There was a problem hiding this comment.
This needs to be updated once y-scope/eslint-config-yscope#3 is merged and a new version is published.
There was a problem hiding this comment.
This comment no longer applies.
The linting rules are indeed ported to tsconfig.node.ts and tsconfig.app.ts though.
| ], | ||
| }, | ||
| }; | ||
|
|
||
| export default () => { |
There was a problem hiding this comment.
The attempt to migrate to Vite was effortless and they provide all what we need with very simple configuration interfaces. I think we can stick with Vite in this project.
junhaoliao
changed the title
junhaoliao
requested review from
haiqi96 and
davemarco
and removed request for
kirkrodrigues
|
hey |
Description
Validation performed
clp-package/sbin/compress.sh ~/samples/hive-24hr.Debug mode
clp-package/sbin/stop-clp.sh log_viewer_webui.cd clp/component/log-viewer-webui; npm i; npm start8080and observed successful extraction job completion. The redirection to yscope-log-viewer would not work because the viewer app is not served at the same address.Summary by CodeRabbit
Summary by CodeRabbit
Release Notes: Log Viewer Web UI Update
New Features
Improvements
Technical Updates
Performance
These updates introduce a more robust and maintainable web UI for the log viewer, with improved type checking and development experience.