Introduction to ReactJS Code Review for Developers
If you’ve worked with React, you’re likely familiar with the code review process in frontend. If not, here’s a quick breakdown: it’s a practice that improves code quality, catches bugs, and keeps the team aligned with project updates.
There are a few ways to improve your React code review, and I’ll share them with you. I’ll point out what you should look for during the process and how to provide useful comments instead of non-answers like “change A to B”.
Before we move on to that, let’s start with a simple question.
What Is the Goal of the React Code Review?
Catching bugs and producing high-quality work are important parts of code reviews. However, the main focus should be on sharing knowledge and boosting the confidence of your team.
Accepting a pull request should be seen as recognition of a job well done, and reinforce a positive team environment. A good code review should include a showcase of changes made to the project, so other devs can stay informed about the ongoing development of React components, along with feedback sessions. These encourage exploring different approaches to problem-solving and help mentor less experienced React devs.
Things to Consider Before a Code Review
Not all code reviews are the same. Your approach will depend on how familiar you are with the project. If you’re part of the team working on the codebase, you have the advantage of knowing the context, patterns, and potential pitfalls. This makes it easier to catch functional issues, ensure backward compatibility, and improve overall code consistency.
However, If you’re evaluating a project you haven’t worked on before, don’t stress about missing certain details. You don’t have to know every decision behind the code structure. Focus on asking questions when something isn’t clear. Curiosity is key to providing meaningful feedback. If you spot a problem, great! If not, your role is to ensure the submission is readable, maintainable, and follows best code practices.
Setting Rules
Before jumping into a code review, it helps to establish some basic rules. Having a structured process makes reviews more efficient, reduces frustration, and ensures that feedback is constructive. Here are a few ground rules I’ve set up for myself and my team:
Lint the Code Before Submission – Linting is the process of analyzing code to identify potential errors, coding style violations, and other issues. It helps improve code quality, catch bugs early, and promotes consistent coding standards across the project. If developers actively run linting and fix issues before submitting their code, it makes the review process easier for the team.
Self-Review Before Submitting – It’s important for developers should review their code directly on the platform before sharing the link with a reviewer to minimize unnecessary comments,
console.logstatements, formatting issues, and other leftovers.Include a Description in the Pull Request – A summary helps the reviewer understand the context. It doesn’t need to be overly descriptive, just enough to give context.
Attach Screenshots for UI Changes – Sometimes it’s a good idea to send some screenshots, so the reviewer doesn’t have to run the project (unless they have to test it).
Avoid Large Pull Requests – The more files in a PR, the fewer comments it will get, and nobody has time to review hundreds of changes in detail. If a feature is large, create a separate branch for it and break it into smaller sub-branches with focused changes.
Best Practices for Code Review
Beyond just setting rules, a good review requires a thoughtful approach:
Be Communicative
Like in a real conversation, how and when you deliver your feedback is very important:
Offer Explanations – Don’t just demand changes, explain why they’re necessary so the engineer whose code you’re reviewing can learn from the process.
Point Out Good Work – Offer praise where it’s due to keep your teammates motivated.
Mention When You’ll Review the Code – Even experienced React developers can have a tendency to wait for feedback before starting other work. Let your teammate know when you’ll be able to take care of it, and if you are too busy for an in-depth check, mention it too.
Categorize Comments
A good way to keep feedback clear and constructive is to divide comments into three types:
Major – These are critical issues devs have to fix before merging. They could break the app, cause regressions, or fail to meet requirements.
Minor – Suggestions for improving readability, reusability, or general code quality. If the developer has a solid reason for their approach, it’s okay to leave things as they are.
Optional – Small tweaks like formatting or syntax updates that don’t affect functionality.
Stay Organized
Even if ten other developers are reviewing the same code, it’s still your responsibility to offer it your full attention:
Make Comments Visible – While transparency is an important factor in building trust, having everyone up-to-date about suggested changes is just as valuable. The comments should be visible to everyone involved in the process to avoid feedback loss.
Don’t Waste Time on Repeating Styling Issues – In my experience, most comments in React code reviews are about styling issues. If you encounter styling concerns throughout the React codebase, address them once, and propose solutions to avoid leaving the same comments on each request.
18 Tips for a React Code Review – Checklist
A checklist can make reviews more systematic and prevent common issues from slipping through. Have a look at the overview of what to keep in mind for a better React code review:
Download a checklist for a better code review
Check if there are any new npm packages added.
Ensure there are no functionality duplicates like
date-fns + moment.Look for imports. Sometimes tree shaking might not work as expected, and there’s an option to bundle the whole library with a single method:
import _ from 'lodash';
//should became more precise import like:
import uniq from 'lodash/uniq';
- If your app uses translations, see if all new areas have also been translated. If not, point that out and the developer should be aware of that in the future.
const NewComponent = () => {
return (
<div>
New static text inside new component should be translated!
</div>
)
}
- Check for missing or invalid types if you are using TypeScript. All “ANY” types should also be fixed unless you have a really, really good explanation for not doing so. Below we have missing props types and any in the method.
const NewComponent = ({items, data}) => {
const getItemId = (data: any) => data.id
return (
<div>
{items.map(item => (
<span key={getItemId(item)}>
<h1>{item.title}</h1>
<p>{item.description}</p>
</span>
))}
</div>
)
}
See variables, functions, and naming conventions. They should all declare their name and function
For boolean values, use prefixes is/are/should to declare their behaviour
(visible => isVisible)so they won’t be treated as HTML properties.Make sure functions declare their purpose; if they return anything, name them accordingly. For example, if they manipulate data: updateUsers => addUniqId, parseData => parseToAPIFormat, etc.
Look for weird logic patterns. Sometimes when a dev spends too much time on a task, they get creative with the code and develop methods or flows that have no sense and can affect the project structure.
Are code chunks too complicated? If someone is adding an ID into an array using 20 lines of code instead of 1, let them know why they shouldn’t do that.
If you can’t understand what a specific chunk of code is doing, request an explanation from the developer to clear out any potential confusion.
Avoid hard-coded values. Check for hardcoded names, paths, and values in the code. Instead of embedding them directly, store them in constants or configuration files so they can be updated in one place.
Maintain backward compatibility. Keep an eye out for changes that could break existing functionality, such as making optional props required or modifying function parameters. In TypeScript, these issues trigger compilation errors, but in JavaScript, they must be tracked manually to prevent unexpected failures.
Ensure there’s no code repetition. If you’ve seen the same/similar logic in multiple places, point that out.
Check for missing form validations or incorrect form validations. I’ve never seen React apps that have a form without field validation.
Be aware of missing error handlers from API responses to provide appropriate feedback to users. Pay attention to try/catch blocks and their handling in catch.
Optimize async methods. Decide whether async methods can run in parallel or need to execute in sequence, making sure that required data is properly awaited.
Learn from your mistakes. Mistakes are part of the process, but they don’t have to be repeated. If you spot something you’ve struggled with before, use that knowledge to steer things in the right direction.
Summary
In the dev community, the reviewing process should be treated as a great way to provide general coding knowledge. A structured review process improves code quality, encourages insight sharing, and strengthens relationships in the team. While it does help provide feedback, it shouldn’t focus on pointing out issues, but on suggesting solutions and keeping the process productive. Explaining why something needs to change helps developers improve faster, and small wording tweaks can make feedback more constructive.
Top comments (0)