Inline SVG logo to eliminate navigation flash#667
Conversation
|
|
Important Review skippedBot user detected. To trigger a single review, invoke the You can disable this status message by setting the WalkthroughReplaced Next/Image usage with an inline SVG in the Logo component and updated tests to assert the inline SVG is rendered (checking SVG presence/attributes). No exported API changes. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (5 passed)
Comment |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Co-authored-by: yamcodes <2014360+yamcodes@users.noreply.github.com>
Co-authored-by: yamcodes <2014360+yamcodes@users.noreply.github.com>
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![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 (2)
apps/www/components/page/logo.test.tsx (2)
19-22: Consider refactoring the SVG query and viewBox assertion.The
document.querySelector("svg")approach bypasses accessibility-first querying, and checking theviewBoxattribute tests an implementation detail rather than component behavior.Since the SVG is decorative (
aria-hidden="true"in the component), consider querying via the container or parent element instead, and remove the viewBox assertion as it doesn't affect user-facing behavior.🔎 Alternative query approach
it("renders the logo icon", () => { render(<Logo />); - // Check for the inline SVG element - const svg = document.querySelector("svg"); + const container = screen.getByText("ArkEnv").parentElement; + const svg = container?.querySelector("svg"); expect(svg).toBeInTheDocument(); - expect(svg).toHaveAttribute("viewBox", "0 0 12 12"); });Based on coding guidelines and learnings emphasizing accessibility-first queries and testing behavior over implementation details.
38-40: Optional: Reconsider testing CSS classes.The guidelines suggest avoiding tests that check pure styling or CSS classes. While this test maintains the existing pattern, consider whether the
size-6class assertion provides value for the component's public API contract.Based on coding guidelines discouraging CSS class testing in favor of behavior testing.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/www/components/page/logo.test.tsxapps/www/components/page/logo.tsx
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
**/*.{ts,tsx}: Prefertypeoverinterfacefor type definitions in TypeScript
Use TypeScript 5.1+ features when appropriate
Leverageconsttype parameters for better inference in TypeScript
Use JSDoc comments for public APIs
Use tabs for indentation (configured in Biome)
Use double quotes for strings (configured in Biome)
Organize imports automatically (Biome handles this)
Avoid explicit types when TypeScript can infer them (noInferrableTypeserror)
Useas constwhere appropriate for immutable values (useAsConstAssertionerror)
Don't reassign function parameters (noParameterAssignerror)
Place default parameters last in function signatures (useDefaultParameterLasterror)
Always initialize enum values (useEnumInitializerserror)
Declare one variable per statement (useSingleVarDeclaratorerror)
Avoid unnecessary template literals (noUnusedTemplateLiteralerror)
PreferNumber.parseIntover globalparseInt(useNumberNamespaceerror)
Use kebab-case for TypeScript filenames (e.g.,create-env.ts)
Use camelCase for function names (e.g.,createEnv)
Use PascalCase for type names (e.g.,ArkEnvError)
Use UPPER_SNAKE_CASE for environment variables and constants
Include examples in JSDoc comments when helpful for public APIs
Document complex type logic with JSDoc comments
UseArkEnvErrorfor environment variable validation errors
Provide clear, actionable error messages that include the variable name and expected type
**/*.{ts,tsx}: UsecreateEnv(schema)function (or default import asarkenv) to create validated environment objects in TypeScript
Use built-in validators (host, port, url, email) from ArkEnv when available instead of custom ArkType schemas
Provide default values for optional environment variables using ArkType syntax (e.g., 'boolean = false')
Use ArkEnvError for environment variable errors instead of generic Error types
For environment schema definition, use ArkType string literal syntax for enumerated values (e.g., "'deve...
Files:
apps/www/components/page/logo.tsxapps/www/components/page/logo.test.tsx
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
Use self-closing JSX elements (
useSelfClosingElementserror)
Files:
apps/www/components/page/logo.tsxapps/www/components/page/logo.test.tsx
apps/www/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (apps/www/.cursor/rules/posthog-integration.mdc)
apps/www/**/*.{ts,tsx,js,jsx}: If using TypeScript, use an enum to store feature flag names. If using JavaScript, store feature flag names as strings to an object declared as a constant to simulate an enum. Use UPPERCASE_WITH_UNDERSCORE naming convention for enum/const object members.
If a custom property for a person or event is referenced in two or more files or two or more callsites in the same file, use an enum or const object with UPPERCASE_WITH_UNDERSCORE naming convention, similar to feature flags.
Files:
apps/www/components/page/logo.tsxapps/www/components/page/logo.test.tsx
**/*.test.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
Co-locate tests with components:
Component.tsxnext toComponent.test.tsx
**/*.test.{ts,tsx}: Use Vitest for unit and integration tests
Test individual functions, components, and hooks in isolation with mocked dependencies in unit tests
Unit tests should focus on individual function logic and edge cases, component rendering and props, error handling and validation, and type checking
Unit tests should execute in less than 100ms per test
Mock external dependencies (clipboard, network, etc.) in unit tests
Co-locate unit test files with source files using naming convention: source file → test file (e.g., create-env.ts → create-env.test.ts)
Test component behavior, not aesthetics, and focus on what users can do and what the component guarantees through its API
Test component public API (props, events, and component contract), user behavior (clicks, typing, focus, keyboard, ARIA), state transitions, accessibility, and side effects in component tests
Do not test pure styling or CSS classes, library internals (Radix/shadcn), implementation details (hooks, setState, private variables), or visual variants in component tests
Use Testing Library with user-event for real user simulation in component tests
Query by role, name, label, and text (accessibility first) in component tests
Use beforeEach/afterEach for cleanup, not beforeAll/afterAll when possible
Keep tests fast, deterministic, and parallelizable
Mock at component boundaries (network, time, context)Create unit tests with
.test.tsor.test.tsxsuffix located alongside source files, testing individual functions and components in isolation with mocked dependencies
Files:
apps/www/components/page/logo.test.tsx
**/*.{test,integration.test}.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{test,integration.test}.{ts,tsx}: Use Vitest'sdescribe/itstructure for all test files
Test both success and failure cases in unit and integration tests
Mockprocess.envin unit tests to test different environment variable scenarios
Files:
apps/www/components/page/logo.test.tsx
🧠 Learnings (11)
📓 Common learnings
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Test component public API (props, events, and component contract), user behavior (clicks, typing, focus, keyboard, ARIA), state transitions, accessibility, and side effects in component tests
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Test component behavior, not aesthetics, and focus on what users can do and what the component guarantees through its API
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Test component public API (props, events, and component contract), user behavior (clicks, typing, focus, keyboard, ARIA), state transitions, accessibility, and side effects in component tests
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Test component behavior, not aesthetics, and focus on what users can do and what the component guarantees through its API
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Do not test pure styling or CSS classes, library internals (Radix/shadcn), implementation details (hooks, setState, private variables), or visual variants in component tests
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Unit tests should focus on individual function logic and edge cases, component rendering and props, error handling and validation, and type checking
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.integration.test.{ts,tsx} : Integration tests should focus on component and hook interactions, function composition and data flow, real dependencies between units, and state synchronization across boundaries
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-23T07:09:57.130Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-23T07:09:57.130Z
Learning: Applies to **/*.{test,integration.test}.{ts,tsx} : Test both success and failure cases in unit and integration tests
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Query by role, name, label, and text (accessibility first) in component tests
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.integration.test.{ts,tsx} : Test how multiple units (components, hooks, functions) work together without mocking their interactions in integration tests
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to tooling/playwright-www/**/*.{ts,tsx} : End-to-end tests should focus on user-facing behavior, not implementation details
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-23T07:09:57.130Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-23T07:09:57.130Z
Learning: Applies to **/*.test.{ts,tsx} : Create unit tests with `.test.ts` or `.test.tsx` suffix located alongside source files, testing individual functions and components in isolation with mocked dependencies
Applied to files:
apps/www/components/page/logo.test.tsx
🔇 Additional comments (1)
apps/www/components/page/logo.tsx (1)
12-43: LGTM! Inline SVG successfully eliminates external asset loading.The implementation correctly replaces the Image component with an inline SVG, using Tailwind theme classes for color support and
aria-hidden="true"for decorative content. The mix of Tailwind classes and inline styles is appropriate for SVG-specific properties that lack Tailwind equivalents.
github-actions
bot
added
www
|
@copilot apps/www/components/page/logo.test.tsx (2) 1- The document.querySelector("svg") approach bypasses accessibility-first querying, and checking the viewBox attribute tests an implementation detail rather than component behavior. Since the SVG is decorative (aria-hidden="true" in the component), consider querying via the container or parent element instead, and remove the viewBox assertion as it doesn't affect user-facing behavior. 2- 38-40: Optional: Reconsider testing CSS classes. The guidelines suggest avoiding tests that check pure styling or CSS classes. While this test maintains the existing pattern, consider whether the size-6 class assertion provides value for the component's public API contract. |
Co-authored-by: yamcodes <2014360+yamcodes@users.noreply.github.com>
Updated the test in commit cbf88b4:
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
apps/www/components/page/logo.test.tsx (1)
26-38: Remove CSS class assertions per coding guidelines.This test violates the explicit coding guideline: "Do not test pure styling or CSS classes."
Testing Tailwind utility classes (
flex,items-center,gap-2,font-medium,text-fd-foreground,text-sm) creates brittle coupling to styling implementation. These tests will break if you refactor styles (e.g., switching to CSS modules or different utility classes) even when visual appearance remains identical.Recommendation: Remove this entire test case. Component styling is an implementation detail, not part of the public API contract.
Based on coding guidelines and your optional PR comment about reconsidering CSS class tests.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
apps/www/components/page/logo.test.tsx
🧰 Additional context used
📓 Path-based instructions (5)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
**/*.{ts,tsx}: Prefertypeoverinterfacefor type definitions in TypeScript
Use TypeScript 5.1+ features when appropriate
Leverageconsttype parameters for better inference in TypeScript
Use JSDoc comments for public APIs
Use tabs for indentation (configured in Biome)
Use double quotes for strings (configured in Biome)
Organize imports automatically (Biome handles this)
Avoid explicit types when TypeScript can infer them (noInferrableTypeserror)
Useas constwhere appropriate for immutable values (useAsConstAssertionerror)
Don't reassign function parameters (noParameterAssignerror)
Place default parameters last in function signatures (useDefaultParameterLasterror)
Always initialize enum values (useEnumInitializerserror)
Declare one variable per statement (useSingleVarDeclaratorerror)
Avoid unnecessary template literals (noUnusedTemplateLiteralerror)
PreferNumber.parseIntover globalparseInt(useNumberNamespaceerror)
Use kebab-case for TypeScript filenames (e.g.,create-env.ts)
Use camelCase for function names (e.g.,createEnv)
Use PascalCase for type names (e.g.,ArkEnvError)
Use UPPER_SNAKE_CASE for environment variables and constants
Include examples in JSDoc comments when helpful for public APIs
Document complex type logic with JSDoc comments
UseArkEnvErrorfor environment variable validation errors
Provide clear, actionable error messages that include the variable name and expected type
**/*.{ts,tsx}: UsecreateEnv(schema)function (or default import asarkenv) to create validated environment objects in TypeScript
Use built-in validators (host, port, url, email) from ArkEnv when available instead of custom ArkType schemas
Provide default values for optional environment variables using ArkType syntax (e.g., 'boolean = false')
Use ArkEnvError for environment variable errors instead of generic Error types
For environment schema definition, use ArkType string literal syntax for enumerated values (e.g., "'deve...
Files:
apps/www/components/page/logo.test.tsx
**/*.tsx
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
Use self-closing JSX elements (
useSelfClosingElementserror)
Files:
apps/www/components/page/logo.test.tsx
**/*.test.{ts,tsx}
📄 CodeRabbit inference engine (.cursor/rules/coding-guidelines.mdc)
Co-locate tests with components:
Component.tsxnext toComponent.test.tsx
**/*.test.{ts,tsx}: Use Vitest for unit and integration tests
Test individual functions, components, and hooks in isolation with mocked dependencies in unit tests
Unit tests should focus on individual function logic and edge cases, component rendering and props, error handling and validation, and type checking
Unit tests should execute in less than 100ms per test
Mock external dependencies (clipboard, network, etc.) in unit tests
Co-locate unit test files with source files using naming convention: source file → test file (e.g., create-env.ts → create-env.test.ts)
Test component behavior, not aesthetics, and focus on what users can do and what the component guarantees through its API
Test component public API (props, events, and component contract), user behavior (clicks, typing, focus, keyboard, ARIA), state transitions, accessibility, and side effects in component tests
Do not test pure styling or CSS classes, library internals (Radix/shadcn), implementation details (hooks, setState, private variables), or visual variants in component tests
Use Testing Library with user-event for real user simulation in component tests
Query by role, name, label, and text (accessibility first) in component tests
Use beforeEach/afterEach for cleanup, not beforeAll/afterAll when possible
Keep tests fast, deterministic, and parallelizable
Mock at component boundaries (network, time, context)Create unit tests with
.test.tsor.test.tsxsuffix located alongside source files, testing individual functions and components in isolation with mocked dependencies
Files:
apps/www/components/page/logo.test.tsx
apps/www/**/*.{ts,tsx,js,jsx}
📄 CodeRabbit inference engine (apps/www/.cursor/rules/posthog-integration.mdc)
apps/www/**/*.{ts,tsx,js,jsx}: If using TypeScript, use an enum to store feature flag names. If using JavaScript, store feature flag names as strings to an object declared as a constant to simulate an enum. Use UPPERCASE_WITH_UNDERSCORE naming convention for enum/const object members.
If a custom property for a person or event is referenced in two or more files or two or more callsites in the same file, use an enum or const object with UPPERCASE_WITH_UNDERSCORE naming convention, similar to feature flags.
Files:
apps/www/components/page/logo.test.tsx
**/*.{test,integration.test}.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{test,integration.test}.{ts,tsx}: Use Vitest'sdescribe/itstructure for all test files
Test both success and failure cases in unit and integration tests
Mockprocess.envin unit tests to test different environment variable scenarios
Files:
apps/www/components/page/logo.test.tsx
🧠 Learnings (10)
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Test component public API (props, events, and component contract), user behavior (clicks, typing, focus, keyboard, ARIA), state transitions, accessibility, and side effects in component tests
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Do not test pure styling or CSS classes, library internals (Radix/shadcn), implementation details (hooks, setState, private variables), or visual variants in component tests
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Test component behavior, not aesthetics, and focus on what users can do and what the component guarantees through its API
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.integration.test.{ts,tsx} : Integration tests should focus on component and hook interactions, function composition and data flow, real dependencies between units, and state synchronization across boundaries
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.test.{ts,tsx} : Unit tests should focus on individual function logic and edge cases, component rendering and props, error handling and validation, and type checking
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-11-24T16:04:00.957Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/coding-guidelines.mdc:0-0
Timestamp: 2025-11-24T16:04:00.957Z
Learning: Applies to **/*.test.{ts,tsx} : Co-locate tests with components: `Component.tsx` next to `Component.test.tsx`
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-23T07:09:57.130Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-23T07:09:57.130Z
Learning: Applies to **/*.integration.test.{ts,tsx} : Create integration tests with `.integration.test.ts` or `.integration.test.tsx` suffix, testing how multiple units work together without mocking their interactions (except external APIs)
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-23T07:09:57.130Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-12-23T07:09:57.130Z
Learning: Applies to **/*.test.{ts,tsx} : Create unit tests with `.test.ts` or `.test.tsx` suffix located alongside source files, testing individual functions and components in isolation with mocked dependencies
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-26T19:27:11.710Z
Learnt from: danciudev
Repo: yamcodes/arkenv PR: 614
File: packages/vite-plugin/src/index.test.ts:641-654
Timestamp: 2025-12-26T19:27:11.710Z
Learning: In packages/vite-plugin/src/**/*.test.ts: The test suite uses `env.test` files (without leading dot) as test fixtures that are manually read by the `readTestConfig` helper function and stubbed into process.env with `vi.stubEnv`, not as files to be read by Vite's loadEnv during tests.
Applied to files:
apps/www/components/page/logo.test.tsx
📚 Learning: 2025-12-12T13:20:01.954Z
Learnt from: CR
Repo: yamcodes/arkenv PR: 0
File: .cursor/rules/test-patterns.mdc:0-0
Timestamp: 2025-12-12T13:20:01.954Z
Learning: Applies to **/*.integration.test.{ts,tsx} : Test how multiple units (components, hooks, functions) work together without mocking their interactions in integration tests
Applied to files:
apps/www/components/page/logo.test.tsx
⏰ 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). (2)
- GitHub Check: test-e2e (e2e)
- GitHub Check: test-e2e (a11y)
🔇 Additional comments (1)
apps/www/components/page/logo.test.tsx (1)
40-46: LGTM - Tests public API contract.This test correctly validates the component's public API by verifying that the
classNameprop is accepted and applied. Unlike the previous test, this doesn't assert internal styling decisions but rather tests the component's prop contract.
| it("renders the logo icon", () => { | ||
| render(<Logo />); | ||
| // Check for the image element | ||
| const img = document.querySelector("img"); | ||
| expect(img).toBeInTheDocument(); | ||
| expect(img).toHaveAttribute( | ||
| "src", | ||
| expect.stringContaining("/assets/icon.svg"), | ||
| ); | ||
| // Check for the inline SVG element via the container | ||
| const logoText = screen.getByText("ArkEnv"); | ||
| const container = logoText.parentElement; | ||
| const svg = container?.querySelector("svg"); | ||
| expect(svg).toBeInTheDocument(); | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Remove or refactor test to focus on behavior rather than implementation details.
This test violates the coding guidelines in multiple ways:
- Uses
querySelector("svg")instead of accessibility-first queries - Tests implementation details (that the logo uses an SVG element internally)
- Since the SVG is decorative (
aria-hidden="true"per PR description), it shouldn't be queried directly
The first test already confirms the Logo component renders successfully by verifying the "ArkEnv" text appears. Testing the internal rendering mechanism provides minimal value and couples the test to implementation rather than behavior.
Recommendation: Remove this test entirely. If specific visual behavior needs verification (e.g., logo displays correctly), consider visual regression testing instead.
Based on coding guidelines: "Do not test implementation details" and "Query by role, name, label, and text (accessibility first)". This aligns with your own PR comment flagging the same concern.
🤖 Prompt for AI Agents
In apps/www/components/page/logo.test.tsx around lines 17 to 24, remove the
entire test that queries container.querySelector("svg") because it tests
implementation details (that the logo uses an SVG) and uses a non-accessibility
query; delete this test block entirely (or replace it with a behavior-focused
assertion that only verifies visible text "ArkEnv" or an accessible role/label
if needed), relying on visual regression for presentation checks.
Fix Header Logo Flash Issue ✅
The header logo SVG takes a second to load and flashes when switching between pages. This is because Next.js Image component processes SVGs which can cause delays.
Summary of Changes:
Technical Solution:
Replaced the
<Image src="/assets/icon.svg">component with an inline SVG element directly in the Logo component. This eliminates the HTTP request and Next.js image processing overhead, providing instant rendering without any flash during navigation.Key Improvements:
stroke-blue-500 dark:stroke-blue-400andfill-blue-500 dark:fill-blue-400for proper light/dark mode supportFiles Changed:
apps/www/components/page/logo.tsx- Inlined SVG with theme colorsapps/www/components/page/logo.test.tsx- Improved test accessibility and removed implementation detail checksOriginal prompt
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.
Summary by CodeRabbit
Refactor
Tests
✏️ Tip: You can customize this high-level summary in your review settings.