Add detailed landing page development plan in docs/frontend_landing_plan.md: - Complete landing page structure (Hero, Problem/Solution, Features, Demo, CTA) - Design guidelines from downloaded skills (typography, color, motion, composition) - Security considerations (XSS prevention, input sanitization, CSP) - Performance targets (LCP <2.5s, bundle <150KB, Lighthouse >90) - Responsiveness and accessibility requirements (WCAG 2.1 AA) - Success KPIs and monitoring setup - 3-week development timeline with daily tasks - Definition of Done checklist Download 10+ frontend/UI/UX skills via universal-skills-manager: - frontend-ui-ux: UI/UX design without mockups - frontend-design-guidelines: Production-grade interface guidelines - frontend-developer: React best practices (40+ rules) - frontend-engineer: Next.js 14 App Router patterns - ui-ux-master: Comprehensive design systems and accessibility - ui-ux-systems-designer: Information architecture and interaction - ui-ux-design-user-experience: Platform-specific guidelines - Plus additional reference materials and validation scripts Configure universal-skills MCP with SkillsMP API key for curated skill access. Safety first: All skills validated before installation, no project code modified. Refs: Universal Skills Manager (github:jacob-bd/universal-skills-manager) Next: Begin Sprint 3 landing page development
50 lines
1.7 KiB
Markdown
50 lines
1.7 KiB
Markdown
---
|
|
title: Early Length Check for Array Comparisons
|
|
impact: MEDIUM-HIGH
|
|
impactDescription: avoids expensive operations when lengths differ
|
|
tags: javascript, arrays, performance, optimization, comparison
|
|
---
|
|
|
|
## Early Length Check for Array Comparisons
|
|
|
|
When comparing arrays with expensive operations (sorting, deep equality, serialization), check lengths first. If lengths differ, the arrays cannot be equal.
|
|
|
|
In real-world applications, this optimization is especially valuable when the comparison runs in hot paths (event handlers, render loops).
|
|
|
|
**Incorrect (always runs expensive comparison):**
|
|
|
|
```typescript
|
|
function hasChanges(current: string[], original: string[]) {
|
|
// Always sorts and joins, even when lengths differ
|
|
return current.sort().join() !== original.sort().join()
|
|
}
|
|
```
|
|
|
|
Two O(n log n) sorts run even when `current.length` is 5 and `original.length` is 100. There is also overhead of joining the arrays and comparing the strings.
|
|
|
|
**Correct (O(1) length check first):**
|
|
|
|
```typescript
|
|
function hasChanges(current: string[], original: string[]) {
|
|
// Early return if lengths differ
|
|
if (current.length !== original.length) {
|
|
return true
|
|
}
|
|
// Only sort/join when lengths match
|
|
const currentSorted = current.toSorted()
|
|
const originalSorted = original.toSorted()
|
|
for (let i = 0; i < currentSorted.length; i++) {
|
|
if (currentSorted[i] !== originalSorted[i]) {
|
|
return true
|
|
}
|
|
}
|
|
return false
|
|
}
|
|
```
|
|
|
|
This new approach is more efficient because:
|
|
- It avoids the overhead of sorting and joining the arrays when lengths differ
|
|
- It avoids consuming memory for the joined strings (especially important for large arrays)
|
|
- It avoids mutating the original arrays
|
|
- It returns early when a difference is found
|