After reviewing hundreds of PRs over the last few years, especially working in fast-paced startup environments, I’ve noticed some frontend mistakes repeat over and over.
Some of these seem harmless at first but often pile up into frustrating tech debt later.
Here are 13 mistakes I’ve repeatedly seen in frontend pull requests—and how you can avoid them.
1️⃣ Keeping Large Arrays/Objects in Global Constants
❗ The Mistake:
Storing large arrays or objects in global constant files.
🚫 Why It’s Bad:
Even if unused, they stay in memory because of their global scope. The garbage collector won’t help you here.
✅ The Fix:
Create wrapper functions that return these values only when needed. This ensures they’re created when required, freeing memory otherwise.
2️⃣ Duplication of Assets (SVGs, Images, HOCs)
❗ The Mistake:
Adding new SVGs or images wherever needed → over time duplicates sneak in.
✅ The Fix:
Maintain a centralized asset or icon library for media and common components. Also, for recurring logic (like showing loaders), build HOCs or reusable components.
3️⃣ Repeating the Same Logic in Multiple Components
❗ The Mistake:
Data fetching logic or transformations duplicated across multiple components.
✅ The Fix:
Abstract into custom hooks. Need to fetch profile info in 3 places? → useProfile()
→ update it in one place later.
4️⃣ Overusing useState
Instead of useRef
❗ The Mistake:
Using useState
to store everything—even values that don’t impact UI.
✅ The Fix:
Use useRef()
for values that don’t require re-renders (e.g., timers, previous state snapshots).
5️⃣ Using useEffect
for Everything
❗ The Mistake:
Triggering actions through useEffect()
even when they should happen directly via user interaction.
✅ The Fix:
Prefer event handlers for actions like button clicks. Use useEffect()
only for true side-effects tied to state or lifecycle changes.
6️⃣ Lifting State Prematurely
❗ The Mistake:
Moving local state higher up in the component tree unnecessarily.
✅ The Fix:
Keep state local by default. Lift it only when multiple components genuinely need access to it.
7️⃣ Overusing React.memo
and useMemo
❗ The Mistake:
Adding React.memo()
and useMemo()
everywhere just because they exist.
✅ The Fix:
Optimize only where profiling shows performance bottlenecks.
8️⃣ Prop Drilling Hell
❗ The Mistake:
Passing data through 4-5 layers of components → painful.
✅ The Fix:
Use React Context responsibly for module-level shared data. Don’t over-nest contexts react—composition patterns help here.
9️⃣ Tedious Nested State Updates
❗ The Mistake:
Manually writing deep updates with spread operators for every nested object change.
✅ The Fix:
Use immer
→ makes working with complex state structures elegant and easier to maintain.
🔟 Skipping Tests
❗ The Mistake:
Skipping tests for components or utility functions to “save time.”
✅ The Fix:
Write unit tests, especially for complex components or functions. Tests help you understand your own code better.
1️⃣1️⃣ Multiple Components in One File
❗ The Mistake:
Defining multiple components in a single file → chaos over time.
✅ The Fix:
One component per file. Use kebab-case for filenames (user-profile.tsx
).
1️⃣2️⃣ Using Contexts Like Globals
❗ The Mistake:
Creating Context Providers and dumping everything inside them → hard to maintain later.
✅ The Fix:
Adopt composition patterns. Break large contexts into smaller, purpose-driven providers.
1️⃣3️⃣ Inconsistent Folder/File Structures
❗ The Mistake:
Random folder structures, random naming conventions, different import patterns → painful.
✅ The Fix:
Pick a consistent folder structure—feature-based structures work great for React. Use ESLint and Prettier to enforce consistency.
🎯 Final Thoughts
These are not just things I’ve seen in PRs—they’re things I’ve personally done and learned from.
If you’re just starting out in frontend or React, I hope this helps you save time, avoid pitfalls, and write scalable code.
What mistakes have you seen or done in PRs?
Drop them in the comments 👇 I’d love to hear!
Top comments (1)
Was nice to read, thank you!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.