DEV Community

Cover image for 17 Tips from a Senior React Developer
Ndeye Fatou Diop
Ndeye Fatou Diop

Posted on • Originally published at frontendjoy.com

191 5 4 7

17 Tips from a Senior React Developer

I've been writing React code as an engineer at Palantir for the past 5+ years.

These are the 17 tips I wish someone had shared with me when I was starting.

Ready? Let's dive in! 💪

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

1. Learn JavaScript before React

When I first started, I jumped from writing functions and basic DOM manipulation to learning React.

As you can guess, it didn't go well 🤯.

This is a common mistake for junior developers: trying to learn React without a solid understanding of JavaScript.

It's a recipe for confusion:

  • You won't know what is React-specific and what is just JavaScript.

  • Debugging becomes a nightmare.

What to do instead?

Section Divider

2. Read the React docs

You don't need money 💰, a coach, or a fancy course to learn React.

Head to the official React website and:

  • Follow the Quick Start guide.

  • Read the learning chapters (even if they don't make sense initially, they'll click later).

Section Divider

3. Start building projects early

Watching tutorials won't make you a React developer.

Spending $100, $200, or even $700 on courses won't either.

What will? Building projects.

It's the best way to:

  • Learn by making mistakes.

  • Discover gaps in your knowledge.

  • Pick up new patterns and tips.

Stuck for ideas? Try these resources 👇:

Section Divider

4. Use trusted libraries

Not all packages are safe.

For example, in 2021, a popular NPM package, ua-parser-js, was hacked, spreading malware 📛.

To minimize risks:

  • Use libraries from trusted authors.

  • Check for good download volumes and regular updates.

Section Divider

5. Solve problems with Vanilla JS when possible

Previously, you needed libraries like lodash for tasks like cloning, iteration, etc.

But modern JavaScript has improved a lot.

Now, you can achieve a lot with native methods.

So, don’t add a library if you don't have to.

Why?

Every library you add:

  • Increases your app's dependencies, making it more vulnerable to security issues.

  • Potentially adds to your bundle size, slowing down load times.

  • Increases your app’s build/compilation time

  • Creates maintenance overhead to keep dependencies updated.

Before reaching for a library, check if Vanilla JS can do the job. It often can 😉.

Section Divider

6. Optimize bundle size and lazy load as much as possible

It starts slow.

You add one package here.

Then another there.

And then another.

Before you know it:

  • Users complain the app takes too long to load.

  • Developers complain the build process is painfully slow.

Why does this happen?

Packages and heavy components were added without considering their impact on bundle size 🤦‍♀️.

How to fix it?

  • Lazy-load as much as possible.

  • Set up checks to track bundle size increases (Pull Request actions work well for this).

  • Use bundlephobia to check package size before adding it to your project.

Section Divider

7. Colocate related logic

Grouping files by type (e.g., components, utils, i18n) might seem like a good idea, but it's not.

Why?

  • It's harder to follow a component's logic when files are scattered.

  • You risk cleaning a component but forgetting related files.

Instead, keep all a component's logic and assets together in one folder.

Section Divider

8. Keep components simple

Avoid "God" components—those that try to do everything.

They're problematic ❌ because:

  • They're harder to read and understand.

  • They often lead to version control conflicts (Git, GitLab, etc.).

  • Modifying them can unintentionally impact the entire app.

What to do instead?

  • Think about how you'd structure your code if you were working with a teammate.

  • Keep your components focused on one task to minimize conflicts.

This approach keeps your code clean and helps your team work more efficiently.

Section Divider

9. Solve diverse problems

The more problems you solve with React, the better you get 🚀.

Every challenge you tackle teaches you something valuable:

  • You uncover new patterns and anti-patterns.

  • You add more tools to your developer toolbox.

  • You gain confidence in your skills.

But here's the key: don't just practice—vary your practice.

Explore different kinds of problems, projects, and solutions. That variety will help you grow faster as a React developer.

Section Divider

10. Learn good programming patterns

As a React dev, you should also focus on foundational programming skills:

Section Divider

11. Read a ton of React code

Building projects isn't the only way to learn—reading code is just as valuable 💪.

It helps you:

  • Pick up new tips and tricks.

  • Compare approaches to solving problems.

So, check out:

  • Open-source projects on GitHub.

  • Your teammates' code at work.

Section Divider

12. Use TypeScript ASAP

There's a before and an after TypeScript 😅.

Before:

  • You spend extra time double-checking that you've passed the correct props.

  • Debugging can take hours, only to realize you passed the wrong value—or worse, undefined.

After:

  • You focus on structuring your components and defining types.

  • You catch silly mistakes before they reach production.

TypeScript isn't just a tool—it's a game changer for your React workflow.

Section Divider

13. Avoid early abstractions

I used to be guilty of this a lot 🙈.

Whenever I designed a simple component, I'd try to make it reusable and future-proof.

The problem? I often created the wrong abstraction because there were no immediate needs.

This led to two outcomes:

  1. I'd end up refactoring the code later.

  2. Or worse, I'd have to live with the awkward abstraction, making development harder.

What to do instead?

  • Write a component that solves the problem at hand.

  • Extend it only if there's a clear need for reuse, and do so gradually.

For a deeper dive into this topic, check out this great video by Dan Abramov.

Section Divider

14. Use React's built-in state management first

You don't need Redux or Jotai right away.

React's useState, useReducer, and useContext go a long way for simple apps.

Section Divider

15. Don't mindlessly follow online advice

A few years ago, I read online that memoization was "evil."

So, I stopped using it in my React apps.

That was until I crashed an app in production. 😅

The advice made sense for the developer who shared it, but it backfired for me because:

  • I had different use cases.

  • I needed to use effects in my app.

  • I was working with large-scale components.

Main takeaway? Don't mindlessly follow the advice you find online. Instead:

  • Discuss it with your teammates (if you have them).

  • Evaluate whether it applies to your specific context.

Note: With React 19 optimization, this advice may finally be accurate 😅.

Section Divider

16. Make time for refactoring

“When developers are too afraid to clean bad code when they see it; then the system will start to rot. As the rot increases, so does the fear -- so the rot accelerates. At some point the code is such a horrible mess than none of the developers can estimate the effect of a particular change. Adding an icon might break other unrelated things.”

Uncle Bob Martin

Every now and then, you'll notice that:

  • Your React components no longer make sense.

  • They've grown complex or too large.

  • There's room for improvement.

When this happens, take 5–30 minutes to refactor.

Small, regular enhancements can make your components easier to manage and prevent headaches.

Section Divider

17. Only use frameworks when necessary

Spoiler: You don't need a framework to use React.

A simple React, Vite, and react-router setup can go a long way.

Use frameworks like Next.js or Remix only when your app requires their features.

Section Divider

That's a wrap 🎉.

Leave a comment 📩 to share your best tip.

And don't forget to drop a "💖🦄🔥".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or Bluesky.

🐞 SPOT THE BUG

AWS Security LIVE!

Tune in for AWS Security LIVE!

Join AWS Security LIVE! for expert insights and actionable tips to protect your organization and keep security teams prepared.

Learn More

Top comments (55)

Collapse
 
madza profile image
Madza

Solid tips right here, mate! Keep up the awesome job!

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Thanks Madza 🙌

Collapse
 
ianbonaparte profile image
Ian Bonaparte

I agree with almost everything, except I did find that taking the time to learn or study React before diving into making a project helped me, personally. I have been going through Code Academy courses (1-2 hours max usually) before attempting to use a new technology in a project and finding that it helps me at least understand the foundations better, which in turn help me troubleshoot issues in my project better since I actually understand what I'm doing and not just trying to copy + paste from stack overflow ( I still do this, but I understand why I'm doing it :) ).

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Oh 💯.
I myself read some of the react docs and watched some frontendmasters courses to gain confidence.
I think at some point I needed to stop pursuing more courses and just start building and learn along the way!

Collapse
 
ianbonaparte profile image
Ian Bonaparte

Fair! Tutorial hell is real.

Collapse
 
exocody profile image
ExoCody

Great tips! Really loved the focus on "Make time for refactoring." By the way, we’re kicking off 2025 with the launch of Exocoding for React devs. It’s free and makes generating React/JS code super efficient, a great addition to streamline workflows! 😊

I’d love to hear your thoughts or any feedback you might have!

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Thanks a lot! Very cool project idea 😀

Collapse
 
getsetgopi profile image
GP

Awesome! list, and thanks for sharing. I advise the same to my junior developers, that always make sure to master JavaScript even before jumping to other libraries and end up writing code that you don't know how they work.

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Thanks a lot!
Super glad we agree 👍

Collapse
 
chrischism8063 profile image
chrischism8063 • Edited

Excellent write-up!!!

I strongly agree with many of the points here, specifically learn JavaScript before React, building projects in general (this builds confidence), leveraging Typescript asap for UI, using ONLY trusted libraries (this is EXTREMELY IMPORTANT as with my company they have a source to pull security reviewed / approved resources), optimize bundle size and lazy loading (I have to work more on this myself), and use React built-in state management (this can get complex and mess up your application if you don't use it correctly).

What I wanted to add here is what frustrates me about the lack of education when persuaing bachelor's degree (in my experience): always add testing in some sort of form to align to new features. Of course this can add additional work and time to a project and future changes.

This validates important business logic which is the whole purpose of adding new features.

Secondly I would mention also understanding how browser tests work with Selenium (or a similar technology).

Of course, I'm a mid-level systems developer, but there is always something new or a better way to do work in the computer science field.

And third, I would say when having Typescript implemented, I've enjoyed using code generators to scan swagger pages to add existing endpoints and types into the project. If there is a better practice for this process, I would like to understand this more.

My experience thus far has been around manually writing this all up instead of generating the code which can reduce turn-around time to deliver new features.

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Thanks a lot! I am glad we agree on many different points.

Yes, testing is always good. However, the importance depends on your situation. If you're a startup struggling to stay alive and want to test a product quickly, it may not be a priority. Conversely, if you have code critical to many other apps, it is "criminal" not to test it 😅.

I don't know how browser tests work with Selenium. I only use Cypress to write the tests, but I imagine it would be helpful knowledge.

Yes! My backend also automatically generates typescript types: it is life-changing.

Collapse
 
zia_ulhoquebhuiyan_9988 profile image
zia ul Hoque bhuiyan

nice one.

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Thanks 🙏

Collapse
 
nasersss profile image
Naser_Al-Ghaithi

Great tips!

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Thanks 🙏

Collapse
 
jrfrazier profile image
WebDevQuest

10000% I needed these tips about 8 years ago. I hope these tips find someone who is snuggling as I was when I first started.

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Thanks a lot! I am super glad to hear I am not alone 😅

Collapse
 
giseleml profile image
Gisele Leonardi

I'm not sure about number 7. Would you so kindly elaborate on that?

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Hello Gisele,
So I recommend grouping related assets of a component (like in the example here => dev-to-uploads.s3.amazonaws.com/up...)
This is better than having them spread in different folders

Collapse
 
ryder007 profile image
Ameet Kumar Pradhan

Great post! loved it. 👌

Collapse
 
_ndeyefatoudiop profile image
Ndeye Fatou Diop

Thanks 🙏

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

Billboard image

Use Playwright to test. Use Playwright to monitor.

Join Vercel, CrowdStrike, and thousands of other teams that run end-to-end monitors on Checkly's programmable monitoring platform.

Get started now!

👋 Kindness is contagious

Explore a sea of insights with this enlightening post, highly esteemed within the nurturing DEV Community. Coders of all stripes are invited to participate and contribute to our shared knowledge.

Expressing gratitude with a simple "thank you" can make a big impact. Leave your thanks in the comments!

On DEV, exchanging ideas smooths our way and strengthens our community bonds. Found this useful? A quick note of thanks to the author can mean a lot.

Okay