feat(frontend): replace console with custom logger #158
Conversation
I replaced all instances of console.log, console.warn, and console.error with the custom logger @hatchgrid/logger throughout the frontend applications and packages. - I added @hatchgrid/logger as a dependency to client/packages/utilities, client/apps/web, and client/apps/landing-page. - I replaced all console.* calls with the appropriate logger method (e.g., logger.info, logger.warn, logger.error). - I updated tests in useLocalStorage.spec.ts to mock the logger instead of console.warn.
📝 WalkthroughSummary by CodeRabbit
WalkthroughThis change set systematically replaces all direct console logging statements (console.log, console.warn, console.error, console.debug) across multiple frontend applications and libraries with structured logging using the Changes
Sequence Diagram(s)sequenceDiagram
participant Component
participant Logger (@hatchgrid/logger)
participant Console
Note over Component: Previous Flow
Component->>Console: console.log / warn / error(...)
Note over Component: Updated Flow
Component->>Logger: logger.info / warn / error(..., { error })
Logger-->>Console: (Handles structured output)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~18 minutes Poem
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
Deploying hatchgrid-landing-page with
|
| Latest commit: |
30da625
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://11ec0a6b.hatchgrid.pages.dev |
| Branch Preview URL: | https://feature-replace-console-with.hatchgrid.pages.dev |
Deploying hatchgrid-web-app with
|
| Latest commit: |
30da625
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://de972467.hatchgrid-web-app.pages.dev |
| Branch Preview URL: | https://feature-replace-console-with.hatchgrid-web-app.pages.dev |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (22)
client/apps/landing-page/package.json(1 hunks)client/apps/landing-page/src/components/cta-email/CTAEmail.vue(4 hunks)client/apps/landing-page/src/components/ui/cta-email/CTAEmail.vue(3 hunks)client/apps/landing-page/src/i18n/ui.ts(2 hunks)client/apps/landing-page/src/models/category/category.service.ts(2 hunks)client/apps/landing-page/src/models/tag/tag.service.ts(3 hunks)client/apps/landing-page/src/utils/test/mockEmailApi.ts(3 hunks)client/apps/web/package.json(1 hunks)client/apps/web/src/App.vue(3 hunks)client/apps/web/src/account/register/register.vue(3 hunks)client/apps/web/src/components/UserProfile.vue(2 hunks)client/apps/web/src/composables/__tests__/useLocalStorage.spec.ts(4 hunks)client/apps/web/src/composables/useLocalStorage.ts(5 hunks)client/apps/web/src/config/axios-interceptor.ts(3 hunks)client/apps/web/src/i18n/index.ts(6 hunks)client/apps/web/src/i18n/load.locales.ts(4 hunks)client/apps/web/src/layouts/components/AppHeader.vue(3 hunks)client/apps/web/src/router/middleware/loadLayoutMiddleware.ts(3 hunks)client/apps/web/src/services/account.service.ts(5 hunks)client/apps/web/src/stores/auth.ts(3 hunks)client/packages/utilities/package.json(1 hunks)client/packages/utilities/src/theme/color-theme.ts(2 hunks)
🧰 Additional context used
📓 Path-based instructions (7)
client/apps/web/**/*.{vue,ts}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
client/apps/web/**/*.{vue,ts}: Follow composition API and TypeScript best practices in Vue 3 frontend code
Document Vue components with JSDoc or TypeScript comments
Files:
client/apps/web/src/layouts/components/AppHeader.vueclient/apps/web/src/account/register/register.vueclient/apps/web/src/i18n/load.locales.tsclient/apps/web/src/components/UserProfile.vueclient/apps/web/src/config/axios-interceptor.tsclient/apps/web/src/i18n/index.tsclient/apps/web/src/App.vueclient/apps/web/src/router/middleware/loadLayoutMiddleware.tsclient/apps/web/src/stores/auth.tsclient/apps/web/src/composables/useLocalStorage.tsclient/apps/web/src/composables/__tests__/useLocalStorage.spec.tsclient/apps/web/src/services/account.service.ts
client/apps/web/**/*.{js,ts,vue,json}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Use ESLint and Prettier for code consistency in frontend code
Files:
client/apps/web/src/layouts/components/AppHeader.vueclient/apps/web/src/account/register/register.vueclient/apps/web/src/i18n/load.locales.tsclient/apps/web/src/components/UserProfile.vueclient/apps/web/src/config/axios-interceptor.tsclient/apps/web/src/i18n/index.tsclient/apps/web/src/App.vueclient/apps/web/src/router/middleware/loadLayoutMiddleware.tsclient/apps/web/package.jsonclient/apps/web/src/stores/auth.tsclient/apps/web/src/composables/useLocalStorage.tsclient/apps/web/src/composables/__tests__/useLocalStorage.spec.tsclient/apps/web/src/services/account.service.ts
client/apps/web/**/*.{js,ts,vue,css,scss,json}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Use Prettier, ESLint, and Stylelint for code style enforcement
Files:
client/apps/web/src/layouts/components/AppHeader.vueclient/apps/web/src/account/register/register.vueclient/apps/web/src/i18n/load.locales.tsclient/apps/web/src/components/UserProfile.vueclient/apps/web/src/config/axios-interceptor.tsclient/apps/web/src/i18n/index.tsclient/apps/web/src/App.vueclient/apps/web/src/router/middleware/loadLayoutMiddleware.tsclient/apps/web/package.jsonclient/apps/web/src/stores/auth.tsclient/apps/web/src/composables/useLocalStorage.tsclient/apps/web/src/composables/__tests__/useLocalStorage.spec.tsclient/apps/web/src/services/account.service.ts
client/apps/web/**/*.vue
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Use the composition API for Vue components
Files:
client/apps/web/src/layouts/components/AppHeader.vueclient/apps/web/src/account/register/register.vueclient/apps/web/src/components/UserProfile.vueclient/apps/web/src/App.vue
**/*.{kt,ts,js}
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Document public APIs and complex logic with KDoc or JSDoc
Files:
client/apps/landing-page/src/models/category/category.service.tsclient/apps/web/src/i18n/load.locales.tsclient/packages/utilities/src/theme/color-theme.tsclient/apps/web/src/config/axios-interceptor.tsclient/apps/web/src/i18n/index.tsclient/apps/web/src/router/middleware/loadLayoutMiddleware.tsclient/apps/landing-page/src/models/tag/tag.service.tsclient/apps/landing-page/src/i18n/ui.tsclient/apps/web/src/stores/auth.tsclient/apps/landing-page/src/utils/test/mockEmailApi.tsclient/apps/web/src/composables/useLocalStorage.tsclient/apps/web/src/composables/__tests__/useLocalStorage.spec.tsclient/apps/web/src/services/account.service.ts
client/apps/web/**/composables/**/*.ts
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
Isolate logic in composables in Vue 3 frontend code
Files:
client/apps/web/src/composables/useLocalStorage.tsclient/apps/web/src/composables/__tests__/useLocalStorage.spec.ts
client/apps/web/**/*.{test,spec}.ts
📄 CodeRabbit Inference Engine (.github/copilot-instructions.md)
client/apps/web/**/*.{test,spec}.ts: Use Vitest and Vue Test Utils for frontend testing
Keep test coverage high for components and composables in frontend code
Files:
client/apps/web/src/composables/__tests__/useLocalStorage.spec.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Build
- GitHub Check: Analyze (java-kotlin)
- GitHub Check: Cloudflare Pages: hatchgrid-web-app
🔇 Additional comments (42)
client/packages/utilities/package.json (1)
62-62: LGTM: Correct workspace dependency addition.The addition of
@hatchgrid/loggeras a workspace dependency is appropriate for enabling structured logging in the utilities package.client/packages/utilities/src/theme/color-theme.ts (3)
1-1: LGTM: Clean import of the logger.The import statement follows proper ES6 syntax and imports the necessary LogManager for structured logging.
7-7: LGTM: Well-named logger instance.The logger name "utilities:color-theme" follows good conventions for contextual logging, making it easy to identify the source of log messages.
77-77: Excellent structured logging implementation.The replacement of
console.logwithlogger.infoincludes structured data, making it easier to parse and filter logs. The log level is appropriate for this informational message.client/apps/web/package.json (1)
18-18: LGTM: Appropriate dependency addition.The
@hatchgrid/loggerworkspace dependency is correctly added to support structured logging throughout the web application.client/apps/landing-page/package.json (1)
46-46: LGTM: Consistent dependency addition.The workspace dependency for
@hatchgrid/loggeris properly added to enable structured logging in the landing-page application.client/apps/landing-page/src/utils/test/mockEmailApi.ts (3)
6-6: LGTM: Standard logger import.The import statement correctly brings in the LogManager for structured logging implementation.
99-99: LGTM: Well-scoped logger instance.The logger name "landing-page:mock-email-api" clearly identifies the context and follows good naming conventions for test utilities.
138-138: LGTM: Appropriate console replacement.The conversion from
console.logtologger.infomaintains the informational message while introducing structured logging for better development debugging.client/apps/landing-page/src/models/tag/tag.service.ts (2)
7-7: LGTM: Proper logger initializationThe logger import and initialization follow good practices with a descriptive, scoped logger name that clearly identifies the module.
Also applies to: 13-13
63-63: LGTM: Structured error logging implementationThe replacement of
console.errorwithlogger.errorimproves log structure and observability. The error objects are properly wrapped in object literals for structured logging.Also applies to: 79-79
client/apps/web/src/layouts/components/AppHeader.vue (2)
2-2: LGTM: Clean logger integration in Vue componentThe logger is properly imported and initialized with a contextual name that follows the established naming convention.
Also applies to: 25-25
41-41: LGTM: Improved error handling in logout functionThe structured logging approach provides better error tracking and debugging capabilities compared to console.error.
client/apps/web/src/i18n/load.locales.ts (2)
1-1: LGTM: Proper logger setup for i18n moduleThe logger initialization follows the established pattern with a clear, descriptive name for the internationalization context.
Also applies to: 9-9
53-53: LGTM: Enhanced i18n debugging capabilitiesReplacing console calls with structured logging significantly improves debugging capabilities for locale loading issues. The consistent use of both
logger.warnfor missing files andlogger.errorfor load failures provides appropriate log levels.Also applies to: 63-63, 91-91
client/apps/landing-page/src/models/category/category.service.ts (2)
7-7: LGTM: Consistent logger integrationThe logger import and initialization follow the same pattern as the tag service, maintaining consistency across the landing-page models.
Also applies to: 13-13
76-76: LGTM: Proper error logging structureThe structured error logging provides better context and consistency with the rest of the service layer.
client/apps/web/src/config/axios-interceptor.ts (2)
1-1: LGTM: Essential logging for HTTP infrastructureThe logger integration in this critical HTTP interceptor module will significantly improve debugging capabilities for request/response issues.
Also applies to: 13-13
27-27: LGTM: Improved HTTP error visibilityStructured logging in the request interceptor provides much better visibility into HTTP request failures compared to console logging.
client/apps/web/src/stores/auth.ts (2)
1-1: LGTM! Good logger initialization.The logger import and initialization follow consistent naming conventions and best practices for structured logging.
Also applies to: 34-34
130-130: Improved structured logging with minor behavioral change.The replacement of
console.warnwithlogger.warnis good, and passing the error as structured data is an improvement. Note that this changes from conditional to unconditional logging - ensure this increased verbosity is intentional for better observability.client/apps/landing-page/src/i18n/ui.ts (2)
1-1: LGTM! Proper logger setup for i18n module.Logger initialization follows the established naming convention and is appropriately scoped to the i18n-ui module.
Also applies to: 5-5
43-48: Excellent use of debug level for development logging.Replacing
console.logwithlogger.debugis perfect for development-only information. The simplified message format and structured data approach improve readability.client/apps/web/src/composables/__tests__/useLocalStorage.spec.ts (1)
1-1: LGTM! Proper import for logger testing.Adding the LogManager import enables proper testing of the new logging implementation.
client/apps/landing-page/src/components/cta-email/CTAEmail.vue (2)
2-2: LGTM! Well-structured logger initialization.Logger setup follows established naming conventions and is appropriately scoped to the CTA email component.
Also applies to: 61-61
115-118: Excellent structured logging implementation.The logging provides valuable context with appropriate log levels:
logger.infofor successful submissions with email and response datalogger.errorfor failures with error objectsThis enhances observability and debugging capabilities significantly.
Also applies to: 125-125
client/apps/landing-page/src/components/ui/cta-email/CTAEmail.vue (2)
2-2: LGTM! Consistent logger setup for UI component.Logger initialization follows the established pattern with appropriate naming that distinguishes this UI component from the enhanced CTA email component.
Also applies to: 51-51
75-75: Good structured logging replacement.Replacing
console.logwithlogger.infoand using structured data format improves consistency and provides better context for email submissions.client/apps/web/src/account/register/register.vue (2)
105-105: Well-implemented logger integration.The logger import and initialization follow best practices with a contextual name that clearly identifies the module scope.
Also applies to: 124-124
184-184: Excellent structured logging implementation.The replacement of console.error with logger.error properly includes the error object as structured data, which will improve debugging capabilities and log aggregation.
client/apps/web/src/composables/useLocalStorage.ts (2)
1-1: Consistent logger setup following established patterns.The logger import and initialization use the appropriate contextual naming convention that matches other modules in the codebase.
Also applies to: 12-12
29-31: Structured logging enhances error tracking.All console.warn calls have been properly replaced with logger.warn, including error objects as structured data. This will significantly improve debugging capabilities by providing context about localStorage operations failures.
Also applies to: 47-47, 56-56
client/apps/web/src/components/UserProfile.vue (2)
31-31: Proper logger integration in Vue component.The logger setup follows the established naming convention and is appropriately scoped to the component context.
Also applies to: 38-38
66-66: Enhanced error logging for logout failures.The structured logging approach with error object inclusion will provide better insights for debugging logout issues compared to the previous generic console.warn.
client/apps/web/src/i18n/index.ts (3)
1-1: Clean logger setup for i18n module.The logger initialization follows the established pattern with appropriate contextual naming for internationalization operations.
Also applies to: 24-24
34-34: Appropriate debug logging for fallback scenarios.Using logger.debug for localStorage unavailability and browser language detection failures is the correct log level, as these are expected fallback conditions rather than errors.
Also applies to: 46-46
76-78: Structured warning logs for locale operations.The replacement of console.warn with logger.warn provides better context for locale-related issues, including error objects for improved debugging.
Also applies to: 95-95
client/apps/web/src/App.vue (3)
9-9: Appropriate logger setup for main application context.The logger initialization with "web:app" context is well-suited for the main application component and follows the established naming pattern.
Also applies to: 16-16
35-35: Enhanced success logging for CSRF initialization.Using logger.info for successful CSRF token initialization provides better visibility into the application startup process compared to conditional console logging.
37-39: Structured error logging improves debugging.The replacement of conditional console.error calls with logger.error, including error objects as structured data, will significantly improve debugging capabilities for CSRF token initialization failures.
Also applies to: 48-48
client/apps/web/src/services/account.service.ts (1)
1-1: Scoped logger set-up looks goodImporting
LogManagerand instantiating a"web:account-service"logger aligns with the new logging strategy.Also applies to: 25-25
client/apps/web/src/router/middleware/loadLayoutMiddleware.ts (1)
1-1: Scoped logger initialization approvedUsing
"web:load-layout-middleware"keeps log namespaces consistent.Also applies to: 13-13
| import type Category from "./category.model"; | ||
|
|
||
| const logger = LogManager.getLogger("landing-page:category-service"); | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Minor formatting nitpick
There's an extra blank line that could be removed for cleaner code formatting.
const logger = LogManager.getLogger("landing-page:category-service");
-📝 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.
| const logger = LogManager.getLogger("landing-page:category-service"); |
🤖 Prompt for AI Agents
In client/apps/landing-page/src/models/category/category.service.ts at line 14,
remove the extra blank line to improve code formatting and maintain consistency.
| const logger = LogManager.getLogger("web:use-local-storage"); | ||
| const loggerSpy = vi.spyOn(logger, "warn").mockImplementation(() => {}); |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Consider extracting logger spy setup to reduce duplication.
The logger mocking pattern is correctly implemented and consistent across tests. However, there's repetition in creating the logger instance and spy setup.
Consider extracting the logger spy setup to a helper function or using beforeEach/afterEach:
describe("useLocalStorage", () => {
const defaultValue = { foo: "bar" };
+ let loggerSpy: ReturnType<typeof vi.spyOn>;
beforeEach(() => {
localStorageMock.clear();
vi.clearAllMocks();
+ const logger = LogManager.getLogger("web:use-local-storage");
+ loggerSpy = vi.spyOn(logger, "warn").mockImplementation(() => {});
});
afterEach(() => {
localStorageMock.clear();
+ loggerSpy?.mockRestore();
});Then remove the individual logger setup from each test and just use expect(loggerSpy).toHaveBeenCalled().
Also applies to: 103-104, 109-110, 120-121, 126-127, 139-140
🤖 Prompt for AI Agents
In client/apps/web/src/composables/__tests__/useLocalStorage.spec.ts around
lines 94 to 95 and similarly at lines 103-104, 109-110, 120-121, 126-127, and
139-140, the logger instance creation and spy setup are duplicated across tests.
To fix this, extract the logger creation and spy setup into a shared helper
function or move it into a beforeEach hook to run before each test. Then remove
the individual logger and spy setup from each test case and rely on the shared
setup, using expect(loggerSpy).toHaveBeenCalled() in the tests to verify calls.
| } | ||
|
|
||
| const logger = LogManager.getLogger("web:axios-interceptor"); | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Minor formatting nitpick
There's an extra blank line that could be removed for consistency.
const logger = LogManager.getLogger("web:axios-interceptor");
-Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In client/apps/web/src/config/axios-interceptor.ts at line 14, remove the extra
blank line to maintain consistent formatting throughout the file.
| logger.error("Failed to load layout component", { error }); | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Capture route & layout in error logs
Including the requested layout and route path makes troubleshooting missing layouts far easier.
-logger.error("Failed to load layout component", { error });
+logger.error("Failed to load layout component", {
+ requestedLayout: layout,
+ routePath: route.fullPath,
+ error,
+});
…
-logger.error("Failed to load default layout", { error: defaultError });
+logger.error("Failed to load default layout", {
+ attemptedLayout: "AppLayout",
+ routePath: route.fullPath,
+ error: defaultError,
+});Also applies to: 39-40
🤖 Prompt for AI Agents
In client/apps/web/src/router/middleware/loadLayoutMiddleware.ts around lines 32
to 33 and 39 to 40, the error logs for failed layout component loading do not
include the requested layout name and route path. Modify the logger.error calls
to include these details in the log context, so the error message contains the
layout identifier and the current route path to improve troubleshooting.
| if (isAxiosError(error)) { | ||
| logger.error("Failed to retrieve application profiles", { | ||
| status: error.response?.status, | ||
| error, | ||
| }); | ||
| } else { | ||
| logger.error("Unknown error retrieving profiles", { error }); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Log additional context for quicker triage
status alone is often insufficient. Including the request URL and (size-bounded) response.data accelerates backend correlation.
logger.error("Failed to retrieve application profiles", {
status: error.response?.status,
+ url: "/actuator/info",
+ responseData: error.response?.data,
error,
});📝 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.
| if (isAxiosError(error)) { | |
| logger.error("Failed to retrieve application profiles", { | |
| status: error.response?.status, | |
| error, | |
| }); | |
| } else { | |
| logger.error("Unknown error retrieving profiles", { error }); | |
| } | |
| if (isAxiosError(error)) { | |
| logger.error("Failed to retrieve application profiles", { | |
| status: error.response?.status, | |
| + url: "/actuator/info", | |
| + responseData: error.response?.data, | |
| error, | |
| }); | |
| } else { | |
| logger.error("Unknown error retrieving profiles", { error }); | |
| } |
🤖 Prompt for AI Agents
In client/apps/web/src/services/account.service.ts around lines 76 to 83, the
error logging only includes the status code, which is insufficient for quick
triage. Update the logger.error call to also include the request URL and a
size-limited version of response.data from the error object, ensuring these
additional details help correlate backend issues faster without overwhelming the
logs.
| logger.error("Failed to retrieve account", { status }); | ||
| } else { | ||
| if (import.meta.env.DEV) { | ||
| console.error("Unknown error retrieving account:", error); | ||
| } | ||
| logger.error("Unknown error retrieving account", { error }); | ||
| } |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Preserve the error object in Axios branch
The Axios branch currently drops the original error instance. Keep it for parity with the generic branch.
-logger.error("Failed to retrieve account", { status });
+logger.error("Failed to retrieve account", { status, error });📝 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.
| logger.error("Failed to retrieve account", { status }); | |
| } else { | |
| if (import.meta.env.DEV) { | |
| console.error("Unknown error retrieving account:", error); | |
| } | |
| logger.error("Unknown error retrieving account", { error }); | |
| } | |
| logger.error("Failed to retrieve account", { status, error }); | |
| } else { | |
| logger.error("Unknown error retrieving account", { error }); | |
| } |
🤖 Prompt for AI Agents
In client/apps/web/src/services/account.service.ts around lines 123 to 126, the
error handling in the Axios branch logs only the status without preserving the
original error object. Modify the Axios error logging to include the original
error instance along with the status, matching the generic branch's behavior to
ensure consistent error information is retained.
| logger.error("Failed to update user language", { error }); | ||
| return false; |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Reuse the Axios discrimination pattern
Mirror the earlier pattern to surface HTTP status codes and distinguish network vs. logic errors.
} catch (error) {
- logger.error("Failed to update user language", { error });
+ if (isAxiosError(error)) {
+ logger.error("Failed to update user language", {
+ status: error.response?.status,
+ error,
+ });
+ } else {
+ logger.error("Unknown error updating user language", { error });
+ }📝 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.
| logger.error("Failed to update user language", { error }); | |
| return false; | |
| } catch (error) { | |
| if (isAxiosError(error)) { | |
| logger.error("Failed to update user language", { | |
| status: error.response?.status, | |
| error, | |
| }); | |
| } else { | |
| logger.error("Unknown error updating user language", { error }); | |
| } | |
| return false; | |
| } |
🤖 Prompt for AI Agents
In client/apps/web/src/services/account.service.ts around lines 226 to 227, the
error logging does not differentiate between HTTP errors and network or logic
errors. Refactor the error handling to follow the existing Axios discrimination
pattern used elsewhere by checking if the error has a response property to log
HTTP status codes, and separately handle network or other errors. Update the
logger.error call to include this distinction and provide clearer error context.
|
This PR was marked as stale due to inactivity. It will be closed automatically in 60 days if there are no updates. |
This pull request introduces a logging enhancement across multiple files in the
landing-pageandwebapps by integrating the@hatchgrid/loggerlibrary. The goal is to replaceconsolestatements with structured logging for better debugging and monitoring. Key changes include initializing loggers in various modules, replacingconsolestatements with logger methods, and updating tests to mock logger calls.Logging Integration:
Dependency Addition:
@hatchgrid/loggeras a dependency inclient/apps/landing-page/package.jsonandclient/apps/web/package.json. [1] [2]Logger Initialization:
CTAEmail.vue,category.service.ts,tag.service.ts,App.vue,register.vue,UserProfile.vue, anduseLocalStorage.ts. Each logger is scoped to its respective module for contextual logging. [1] [2] [3] [4] [5] [6] [7]Replacing
consoleStatements:Info and Debug Logs:
console.logstatements withlogger.infoorlogger.debugto log successful operations, such as email submissions, translation loading, and CSRF token initialization. [1] [2] [3]Error and Warning Logs:
console.errorandconsole.warnwithlogger.errorandlogger.warnfor error handling in email submissions, category and tag fetching, registration, logout, and local storage operations. [1] [2] [3] [4] [5] [6]Test Updates:
useLocalStorage.spec.tsto mock logger methods (logger.warn) instead ofconsolemethods, ensuring consistency with the new logging approach. [1] [2] [3]These changes improve the maintainability and observability of the codebase by introducing structured and contextual logging.