-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: inspira #252
base: main
Are you sure you want to change the base?
feat: inspira #252
Conversation
WalkthroughThe changes introduce a new Changes
Poem
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 (
|
Deploying frontend-mu-nuxt with Cloudflare Pages
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (7)
packages/frontendmu-nuxt/components/home/Hero.vue (1)
Line range hint
8-41
: Consider enhancing component configurabilityThe Hero component's structure is solid, but consider these architectural improvements:
- Make the InspiraVortex component configurable through props to allow reuse in other contexts
- Consider extracting common responsive text sizes to Tailwind theme configuration for consistency
packages/frontendmu-nuxt/components/inspira/Vortex.vue (6)
125-157
: Potential performance improvement inupdateParticle
function.The destructuring of
particleProps
array for each particle can be resource-intensive in a loop. Consider optimizing this by reusing variables or reducing the number of operations inside the loop.You might refactor the code as follows to enhance performance:
-function updateParticle(i: number, ctx: CanvasRenderingContext2D) { +function updateParticle(i: number, ctx: CanvasRenderingContext2D) { const canvas = canvasRef.value if (!canvas) return - const [x, y, vx, vy, life, ttl, speed, radius, hue] = [ - particleProps[i], - particleProps[i + 1], - particleProps[i + 2], - particleProps[i + 3], - particleProps[i + 4], - particleProps[i + 5], - particleProps[i + 6], - particleProps[i + 7], - particleProps[i + 8], - ] + const x = particleProps[i] + const y = particleProps[i + 1] + const vx = particleProps[i + 2] + const vy = particleProps[i + 3] + const life = particleProps[i + 4] + const ttl = particleProps[i + 5] + const speed = particleProps[i + 6] + const radius = particleProps[i + 7] + const hue = particleProps[i + 8] const n = noise3D(x * xOff, y * yOff, tick * zOff) * noiseSteps * TAU const nextVx = lerp(vx, Math.cos(n), 0.5) const nextVy = lerp(vy, Math.sin(n), 0.5) drawParticle(x, y, x + nextVx * speed, y + nextVy * speed, life, ttl, radius, hue, ctx) particleProps[i] = x + nextVx * speed particleProps[i + 1] = y + nextVy * speed particleProps[i + 2] = nextVx particleProps[i + 3] = nextVy particleProps[i + 4] = life + 1 if (checkBounds(x, y, canvas) || life > ttl) { initParticle(i) } }
126-129
: Null check forcanvasRef.value
redundancy.The null check for
canvasRef.value
is performed in multiple functions (updateParticle
,initParticle
). Since these functions are called in a loop wherecanvasRef.value
is unlikely to change, consider moving the null check to a higher level to avoid repeated checks.
186-192
: Unused parameterctx
inresize
function.The
resize
function accepts an optionalctx
parameter, but it is not used within the function. Consider removing the parameter if it's unnecessary.Apply this diff to remove the unused parameter:
-function resize(canvas: HTMLCanvasElement, ctx?: CanvasRenderingContext2D) { +function resize(canvas: HTMLCanvasElement) { const { innerWidth, innerHeight } = window canvas.width = innerWidth canvas.height = innerHeight center[0] = 0.5 * canvas.width center[1] = 0.5 * canvas.height }
194-206
: Clarify the purpose of multiple blur filters inrenderGlow
.Using multiple blur filters with different values can impact performance. Ensure that the visual improvement justifies the potential performance cost.
Consider combining the blur effects or optimizing the rendering pipeline to improve performance.
5-14
: Set default prop values usingdefineProps
syntax.The current usage of
withDefaults(defineProps<VortexProps>(), { ... })
might not fully leverage Vue's reactivity system. Consider defining default prop values directly indefineProps
.Refactor the prop definitions as follows:
-const props = withDefaults(defineProps<VortexProps>(), { - particleCount: 700, - rangeY: 100, - baseSpeed: 0.0, - rangeSpeed: 1.5, - baseRadius: 1, - rangeRadius: 2, - baseHue: 220, - backgroundColor: 'transparent', -}) +const props = defineProps<VortexProps>({ + particleCount: { type: Number, default: 700 }, + rangeY: { type: Number, default: 100 }, + baseSpeed: { type: Number, default: 0.0 }, + rangeSpeed: { type: Number, default: 1.5 }, + baseRadius: { type: Number, default: 1 }, + rangeRadius: { type: Number, default: 2 }, + baseHue: { type: Number, default: 220 }, + backgroundColor: { type: String, default: 'transparent' }, +})
2-2
: Consider adding type definitions for imported modules.The import of
'simplex-noise'
might benefit from explicit type definitions to enhance type safety and editor support.Ensure that the
simplex-noise
module has proper TypeScript types installed or consider writing custom typings if necessary.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yaml
is excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (5)
packages/frontendmu-nuxt/components/home/Hero.vue
(1 hunks)packages/frontendmu-nuxt/components/inspira/Vortex.vue
(1 hunks)packages/frontendmu-nuxt/nuxt.config.ts
(1 hunks)packages/frontendmu-nuxt/package.json
(1 hunks)packages/frontendmu-nuxt/tailwind.config.js
(2 hunks)
🔇 Additional comments (13)
packages/frontendmu-nuxt/package.json (4)
24-24
: Verify Vue compatibility with new animation dependencies
The addition of @vueuse/motion
and simplex-noise
aligns with the PR's objective to implement the Vortex component. However, the Vue update to 3.5.x is significant and requires verification.
Let's check for any compatibility issues:
Also applies to: 31-31, 32-32
✅ Verification successful
Vue 3.5.x update and animation dependencies are compatible
The verification shows that:
@vueuse/motion v2.2.6
has a peer dependency ofvue: ">=3.0.0"
, which is compatible with Vue 3.5.x- No issues were found in the repository related to Vue 3.5 compatibility
- The dependencies align with the PR's animation requirements
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check @vueuse/motion compatibility with Vue 3.5
curl -s https://registry.npmjs.org/@vueuse/motion | jq -r '.versions["2.2.6"].peerDependencies // empty'
# Check for any reported issues with Vue 3.5
gh api graphql -f query='
{
search(query: "repo:vueuse/motion is:issue Vue 3.5", type: ISSUE, first: 5) {
nodes {
... on Issue {
title
state
url
}
}
}
}'
Length of output: 366
28-28
: Verify Nuxt version stability and compatibility
The update to [email protected]
seems to be using an unusual version number. This might be a pre-release or unstable version.
Let's verify the latest stable version and any potential breaking changes:
✅ Verification successful
Version 3.14.1592
is the current stable release of Nuxt
The version number 3.14.1592
is actually the latest stable release of Nuxt, as confirmed by the npm registry data. The version is legitimate, properly signed, and maintained by the core Nuxt team (including well-known maintainers like Daniel Roe, Anthony Fu, and Sébastien Chopin). The package metadata shows it's a production-ready release with proper attestations and signatures.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check latest stable Nuxt version
curl -s https://registry.npmjs.org/nuxt | jq -r '."dist-tags".latest'
# Check if this is a pre-release version
curl -s https://registry.npmjs.org/nuxt | jq -r --arg VERSION "3.14.1592" '.versions[$VERSION] // "Version not found"'
Length of output: 5458
17-46
: Verify dependency tree health after multiple updates
Multiple interdependent packages have been updated simultaneously. While individual updates look reasonable, we should verify the overall dependency tree health.
Let's check for any peer dependency conflicts:
✅ Verification successful
Dependencies are compatible and well-aligned
The dependency versions are compatible and follow the expected patterns:
- Vue 3.5.x is compatible with Nuxt 3.14.x
- All version ranges use appropriate semver patterns (^)
- The core dependencies (Vue and Nuxt) are properly aligned for the ecosystem
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for peer dependency warnings
npm ls @vueuse/motion @nuxt/content vue nuxt --json | jq '.problems // empty'
# Look for any duplicate packages
npm ls --json | jq '[.dependencies | to_entries[] | select(.value.dependencies != null) | .key] | group_by(.) | map(select(length > 1))'
Length of output: 598
Script:
#!/bin/bash
# Let's check the actual package versions and their relationships
npm list vue nuxt @vueuse/motion @nuxt/content --depth=1
# Check if there are any peer dependency requirements
cat package.json | jq -r '.peerDependencies // empty'
# Let's also check the Vue and Nuxt compatibility matrix from package.json
cat packages/frontendmu-nuxt/package.json | jq '.dependencies["vue"], .dependencies["nuxt"]'
Length of output: 291
37-37
: Verify stability of @inspira-ui/plugins
The addition of @inspira-ui/[email protected]
appears to be in a very early development stage (version 0.0.1). This could introduce stability risks.
Let's check the package details and recent updates:
✅ Verification successful
@inspira-ui/plugins appears to be properly integrated
The package is being used as a Tailwind plugin for styling configuration, which is a common and safe usage pattern. While the version is early (0.0.1), the implementation is straightforward and isolated to the Tailwind configuration, minimizing potential stability risks. The plugin is:
- Properly imported and setup in
tailwind.config.js
- Used alongside other stable plugins like
@tailwindcss/typography
- Integrated into the build system through the
@nuxtjs/tailwindcss
module
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check package details and stability
curl -s https://registry.npmjs.org/@inspira-ui/plugins | jq -r '.["dist-tags"] // empty'
# Look for any usage examples in the codebase
rg -l "setupInspiraUI|@inspira-ui"
Length of output: 248
Script:
#!/bin/bash
# Check usage in tailwind config
cat packages/frontendmu-nuxt/tailwind.config.js
# Look for plugin setup/initialization
rg -A 5 "setupInspiraUI|@inspira-ui" --type ts --type js --type vue
Length of output: 4950
Script:
#!/bin/bash
# Check for Vue files with correct file extension
rg -A 5 "setupInspiraUI|@inspira-ui" --type-add 'vue:*.vue' --type vue
# Look for plugin initialization in Nuxt configuration
fd -e ts -e js "nuxt.config" --exec cat {}
Length of output: 2007
packages/frontendmu-nuxt/components/home/Hero.vue (3)
13-16
: LGTM! Well-structured heading with proper responsive design
The heading implementation maintains good semantic structure while providing responsive text sizing and dark mode support.
22-24
: LGTM! Well-implemented link with proper styling and transitions
The NuxtLink implementation follows best practices with appropriate hover states and transitions.
8-8
: Verify InspiraVortex component registration and performance impact
The new visual component might affect page load performance. Consider the following recommendations:
- Ensure the component is properly registered in the Nuxt auto-imports
- Consider lazy loading the component if it's not immediately visible
✅ Verification successful
Component is properly registered and optimized for performance
The InspiraVortex
component is actually the Vortex
component from the inspira
directory, which is auto-imported by Nuxt's component auto-import feature. The component is well-implemented with:
- Proper performance optimizations (canvas-based rendering)
- Cleanup on unmount
- Lazy initialization
- Responsive resize handling
- Motion/fade-in animations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify component registration and check for performance considerations
# Check if the component is properly defined
fd -e vue -e ts "InspiraVortex"
# Look for any existing lazy loading patterns in the codebase
rg -l "defineAsyncComponent|lazy" --type vue
Length of output: 106
Script:
#!/bin/bash
# Let's try a different approach to find the component and lazy loading patterns
# Search for InspiraVortex in all files
rg -l "InspiraVortex"
# Search for component registration patterns
rg -l "defineComponent|defineAsyncComponent"
# Look for the actual component file
fd "InspiraVortex"
Length of output: 197
Script:
#!/bin/bash
# Let's check the content of Hero.vue to understand the component usage context
# and look for any imports or component registrations
rg -A 5 -B 5 "InspiraVortex" packages/frontendmu-nuxt/components/home/Hero.vue
# Also search for any component registration in the Nuxt configuration
fd -e ts "nuxt.config"
Length of output: 699
Script:
#!/bin/bash
# Let's check the Nuxt config and components directory structure
# Check Nuxt config content for auto-imports or component registration
cat packages/frontendmu-nuxt/nuxt.config.ts
# Check if InspiraVortex exists in components directory
fd . packages/frontendmu-nuxt/components/
Length of output: 9965
Script:
#!/bin/bash
# Check if InspiraVortex is actually Vortex component from inspira directory
cat packages/frontendmu-nuxt/components/inspira/Vortex.vue
# Also check for any imports in Hero.vue
cat packages/frontendmu-nuxt/components/home/Hero.vue
Length of output: 8252
packages/frontendmu-nuxt/nuxt.config.ts (2)
28-28
: LGTM! Module addition aligns with the new animation features.
The addition of @vueuse/motion/nuxt
module is appropriate for supporting the new <InspiraVortex />
component's animations.
28-28
: Verify dependency and bundle size impact.
Let's ensure the module is properly configured and won't significantly impact the bundle size.
✅ Verification successful
Bundle size impact is minimal and usage is appropriate
The @vueuse/motion
dependency is being used appropriately in the Vortex component with minimal configuration (just basic opacity animation). The package is a lightweight animation utility (v2.2.6) and is only used in a single component, suggesting minimal bundle size impact. The implementation follows Vue's best practices for animation directives.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify @vueuse/motion dependency and analyze potential bundle size impact
# Check if @vueuse/motion is listed in package.json with correct version
echo "Checking package.json for @vueuse/motion dependency..."
cat package.json | jq '.dependencies["@vueuse/motion"] // .devDependencies["@vueuse/motion"]'
# Look for any existing uses of motion directives or components
echo "Checking for existing motion usage..."
rg -l "v-motion|useMotion|MotionPlugin" --type vue
Length of output: 385
Script:
#!/bin/bash
# Let's try a different approach to verify the dependency and its usage
# Check if @vueuse/motion is listed in package.json (searching in all package.json files)
echo "Checking all package.json files for @vueuse/motion..."
fd package.json --exec grep -l "@vueuse/motion" {}
# Look for any existing uses of motion directives or components without file type restriction
echo "Checking for existing motion usage in all files..."
rg -l "v-motion|useMotion|MotionPlugin"
# Check the size of the package
echo "Checking @vueuse/motion package size..."
fd node_modules/@vueuse/motion/dist -t f --exec ls -lh {} || echo "Package not installed in node_modules"
# Look for any motion-related imports
echo "Checking for motion-related imports..."
rg -l "import.*motion"
Length of output: 680
Script:
#!/bin/bash
# Let's check the specific usage and configuration
# Check the content of the component using motion
echo "Checking motion usage in Vortex component..."
cat "packages/frontendmu-nuxt/components/inspira/Vortex.vue"
# Check the package.json to see the exact version
echo "Checking package version..."
cat "packages/frontendmu-nuxt/package.json" | grep -A 5 -B 5 "@vueuse/motion"
# Check if there are any motion-specific configurations
echo "Checking for motion configurations..."
rg -l "motion.*config|configureMotion"
Length of output: 7110
packages/frontendmu-nuxt/tailwind.config.js (2)
149-149
: Verify Inspira UI plugin configuration requirements
The plugin addition looks good, but since this is being used with a new Vortex component, we should ensure all necessary theme configurations are in place.
✅ Verification successful
Let me try another verification approach to check for the plugin configuration and its usage.
Based on the verification results, I can now provide the final response:
The Inspira UI plugin setup appears to be correctly configured
The plugin is properly:
- Imported and required in the tailwind config
- Added to the plugins array in the correct order
- Installed as a dependency (version 0.0.1)
Since this is an early version (0.0.1) of the plugin and it's being used with Vortex components, the minimal setup is sufficient as the plugin likely includes its default configurations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any Inspira UI specific configuration patterns in the codebase
echo "Checking for Inspira UI configuration patterns..."
rg -l "inspira|vortex" --type=vue --type=js --type=ts
# Look for README or documentation in the plugin package
if [ -d "node_modules/@inspira-ui/plugins" ]; then
echo "Checking plugin documentation for required configuration..."
fd -t f "README|readme|CONFIGURATION|configuration" "node_modules/@inspira-ui/plugins"
fi
Length of output: 238
Script:
#!/bin/bash
# Check tailwind config for any Inspira UI related settings
echo "Checking tailwind configuration..."
rg -A 5 -B 5 "setupInspiraUI"
# Look for any theme extensions or configurations
echo "Checking for theme configurations..."
rg "theme:" -A 10 "tailwind.config.js"
# Check for plugin imports and setup
echo "Checking plugin imports..."
rg "inspira" -A 2 -B 2
Length of output: 2842
2-2
: Verify @inspira-ui/plugins package installation
The new plugin import looks correct, but let's ensure it's properly installed and compatible.
packages/frontendmu-nuxt/components/inspira/Vortex.vue (2)
209-212
: Potential redundant drawing in renderToScreen
function.
The renderToScreen
function draws the canvas onto itself without any transformation, which might be redundant. Verify if this step is necessary for the desired visual effect.
Confirm whether drawing the canvas onto itself is intended and produces the desired effect.
87-104
:
Ensure consistent use of variable declarations.
In the initParticle
function, the variables x
, y
, vx
, vy
, etc., are declared without using const
or let
. This could lead to potential scope issues. Make sure to declare variables appropriately.
Apply this diff to fix the variable declarations:
-function initParticle(i: number) {
+function initParticle(i: number) {
+ const canvas = canvasRef.value
+ if (!canvas)
+ return
+
+ const x = rand(canvas.width)
+ const y = center[1] + randRange(props.rangeY)
+ const vx = 0
+ const vy = 0
+ const life = 0
+ const ttl = baseTTL + rand(rangeTTL)
+ const speed = props.baseSpeed + rand(props.rangeSpeed)
+ const radius = props.baseRadius + rand(props.rangeRadius)
+ const hue = props.baseHue + rand(rangeHue)
+
+ particleProps.set([x, y, vx, vy, life, ttl, speed, radius, hue], i)
+}
Likely invalid or redundant comment.
onMounted(() => { | ||
setup() | ||
window.addEventListener('resize', () => { | ||
const canvas = canvasRef.value | ||
const ctx = canvas?.getContext('2d') | ||
if (canvas && ctx) { | ||
resize(canvas, ctx) | ||
} | ||
}) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Handle cleanup of animation frames on component unmounting.
The animation loop initiated by requestAnimationFrame
in the draw
function continues indefinitely. Ensure that the animation loop is stopped when the component is unmounted to prevent memory leaks.
Implement a mechanism to cancel the animation frame on unmount:
+let animationFrameId: number
function draw(canvas: HTMLCanvasElement, ctx: CanvasRenderingContext2D) {
tick++
ctx.clearRect(0, 0, canvas.width, canvas.height)
ctx.fillStyle = props.backgroundColor
ctx.fillRect(0, 0, canvas.width, canvas.height)
drawParticles(ctx)
renderGlow(canvas, ctx)
renderToScreen(canvas, ctx)
- requestAnimationFrame(() => draw(canvas, ctx))
+ animationFrameId = requestAnimationFrame(() => draw(canvas, ctx))
}
onUnmounted(() => {
window.removeEventListener('resize', resizeListener)
+ cancelAnimationFrame(animationFrameId)
})
Committable suggestion skipped: line range outside the PR's diff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MrSunshyne draw
seems to be called recursively. Are you aware if it's ok to leave it as is or should there be some kind of conditional return to break out of the function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (4)
packages/frontendmu-nuxt/components/inspira/Vortex.vue (4)
15-26
: Consider grouping related constantsThe constants are well-defined but could be better organized. Consider grouping related constants (e.g., animation, particle properties, noise) into separate objects for better maintainability.
-const TAU = 2 * Math.PI -const baseTTL = 50 -const rangeTTL = 150 -const particlePropCount = 9 -const rangeHue = 100 -const noiseSteps = 3 -const xOff = 0.00125 -const yOff = 0.00125 -const zOff = 0.0005 +const ANIMATION = { + TAU: 2 * Math.PI, + baseTTL: 50, + rangeTTL: 150, + noiseSteps: 3 +} +const PARTICLE = { + propCount: 9, + rangeHue: 100 +} +const NOISE_OFFSET = { + x: 0.00125, + y: 0.00125, + z: 0.0005 +}
125-157
: Consider performance optimizations for particle updatesThe particle update logic is well-implemented but could be optimized:
- Consider using Web Workers for particle calculations
- Batch particle updates to reduce array access
- Use local variables to cache frequently accessed values
Example optimization for reducing array access:
function updateParticle(i: number, ctx: CanvasRenderingContext2D) { const canvas = canvasRef.value if (!canvas) return + // Cache array access + const props = { + x: particleProps[i], + y: particleProps[i + 1], + vx: particleProps[i + 2], + vy: particleProps[i + 3], + life: particleProps[i + 4], + ttl: particleProps[i + 5], + speed: particleProps[i + 6], + radius: particleProps[i + 7], + hue: particleProps[i + 8] + } - const [x, y, vx, vy, life, ttl, speed, radius, hue] = [ - particleProps[i], - particleProps[i + 1], - particleProps[i + 2], - particleProps[i + 3], - particleProps[i + 4], - particleProps[i + 5], - particleProps[i + 6], - particleProps[i + 7], - particleProps[i + 8], - ] - const n = noise3D(x * xOff, y * yOff, tick * zOff) * noiseSteps * TAU - const nextVx = lerp(vx, Math.cos(n), 0.5) - const nextVy = lerp(vy, Math.sin(n), 0.5) + const n = noise3D(props.x * xOff, props.y * yOff, tick * zOff) * noiseSteps * TAU + const nextVx = lerp(props.vx, Math.cos(n), 0.5) + const nextVy = lerp(props.vy, Math.sin(n), 0.5)
194-206
: Add performance monitoring for render effectsThe glow effect uses multiple render passes which could impact performance on lower-end devices. Consider:
- Adding performance monitoring
- Making the glow effect configurable
- Implementing a fallback for lower-end devices
Example monitoring implementation:
const PERFORMANCE_BUDGET_MS = 16; // 60fps budget let lastFrameTime = performance.now(); function monitorPerformance() { const currentTime = performance.now(); const frameDuration = currentTime - lastFrameTime; if (frameDuration > PERFORMANCE_BUDGET_MS) { console.warn(`Frame took ${frameDuration}ms, exceeding budget of ${PERFORMANCE_BUDGET_MS}ms`); // Potentially disable effects or reduce particle count } lastFrameTime = currentTime; }
234-247
: Consider adding ARIA attributes for accessibilityThe template structure is well-organized, but could benefit from accessibility improvements.
<template> - <div :class="cn('relative h-full w-full', props.containerClass)"> + <div + :class="cn('relative h-full w-full', props.containerClass)" + role="presentation" + aria-hidden="true" + > <div ref="containerRef" v-motion :initial="{ opacity: 0 }" :enter="{ opacity: 1 }" class="absolute inset-0 z-0 flex size-full items-center justify-center bg-transparent" > <canvas ref="canvasRef" /> </div> <div :class="cn('relative z-10', props.class)"> <slot /> </div> </div> </template>
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
packages/frontendmu-nuxt/components/inspira/Vortex.vue
(1 hunks)
🔇 Additional comments (3)
packages/frontendmu-nuxt/components/inspira/Vortex.vue (3)
49-64
: LGTM! Well-implemented utility functions
The utility functions are pure, properly typed, and serve clear purposes.
224-231
: LGTM! Proper lifecycle management
The component correctly handles mounting and cleanup of event listeners.
105-117
:
Critical: Animation frame cleanup missing
The animation loop needs proper cleanup to prevent memory leaks and unnecessary CPU usage when the component is unmounted.
The previous review comment about this issue is still valid. Store the animation frame ID and cancel it on unmount:
+let animationFrameId: number
function draw(canvas: HTMLCanvasElement, ctx: CanvasRenderingContext2D) {
tick++
ctx.clearRect(0, 0, canvas.width, canvas.height)
ctx.fillStyle = props.backgroundColor
ctx.fillRect(0, 0, canvas.width, canvas.height)
drawParticles(ctx)
renderGlow(canvas, ctx)
renderToScreen(canvas, ctx)
- requestAnimationFrame(() => draw(canvas, ctx))
+ animationFrameId = requestAnimationFrame(() => draw(canvas, ctx))
}
onUnmounted(() => {
window.removeEventListener('resize', handleResize)
+ cancelAnimationFrame(animationFrameId)
})
Summary by CodeRabbit
Release Notes
New Features
<InspiraVortex />
to enhance the main section of the app.<Vortex />
, allowing for customizable visual effects.Enhancements
Hero.vue
for better readability.Dependency Updates
simplex-noise
and@vueuse/motion
.Configuration Changes
setupInspiraUI
plugin to Tailwind CSS configuration for extended functionality.