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?
Learn enough JavaScript to get comfortable (check out JavaScript to Know for React).
Then, dive into React.
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).
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 👇:
Frontend Mentor: Projects for all skill levels.
Frontend Practice: Recreate real websites.
Frontend Projects: Varied project ideas.
JavaScript Mastery: A YouTube channel with project-based tutorials.
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.
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 😉.
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.
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.
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.
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.
10. Learn good programming patterns
As a React dev, you should also focus on foundational programming skills:
Data Structures & Algorithms (e.g., sets, maps, recursion).
Principles like those in The Pragmatic Programmer.
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.
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.
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:
I'd end up refactoring the code later.
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.
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.
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 😅.
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.
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.
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
Top comments (61)
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 :) ).
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!
Fair! Tutorial hell is real.
Solid tips right here, mate! Keep up the awesome job!
Thanks Madza 🙌
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.
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.
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!
Thanks a lot! Very cool project idea 😀
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.
Thanks a lot!
Super glad we agree 👍
nice one.
Thanks!
Thanks 🙏
Another important tip and a really common mistake among juniors, learn how to use correctly a useEffect. The useEffect hook is no always necessary and is really easy to use it wrong or use it when it is unnecessary
100%
You should avoid this hook by default!
The first one is absolutelly true, i've started to learn Vue before JS and well... too much scars to say xD
Ahaha same here! I struggled with react for a long time because I didn’t know JS
Helpful article, Ndeye! Thanks for sharing🙌
Thanks Shefali 🙌
It's so refreshing to read an article with actual good advice! 👌 Strong agree with every single point!
Thanks a lot Rense!
It is my pleasure 🙌
Some comments may only be visible to logged-in visitors. Sign in to view all comments.