INTRODUCTION

If you have some experience in writing your own React code, you are probably familiar with the React code review process. If not – it’s a process that helps keep good code in a project, eliminate potential bugs or just check from higher-skilled React developers. It also helps other teammates to work actively and be up to date as they are able to see all code updates.

I will try to point out what you should look for during the react code review process and how to write good statements instead of unnecessary comments like “change A to B”.

But let’s start with the simple question.

WHAT IS THE GOAL OF THE REACT CODE REVIEW?

• Showcase changes made to the project, enabling other developers to stay informed about the ongoing development of react components.
• Provide valuable feedback on react co and share knowledge with teammates, fostering a culture of learning and improvement.
• Mentor less experienced React developers on writing clean and efficient code, enhancing the overall developer’s ability to create quality code.
• Establish a solid understanding of the React app among team members, promoting collaboration and collective expertise.
• Encourage discussions about alternative solutions with fellow React developers, exploring different approaches to problem-solving.
• Identify and address potential issues or bugs, ensuring a robust and reliable application. While catching bugs is an important aspect of code reviews, the main focus should be on knowledge sharing and boosting the confidence of the developer whose code is being reviewed. Accepting a pull request should be seen as recognition of a job well done, reinforcing a positive team environment.

REACT CODE REVIEW REQUIREMENTS

If you are a reviewer, and you do the React code review often – you should set up some rules first.

They will help you stay less angry, as the person that provides React development services and prepares the code review will have specific steps to follow before sending the code to you. Win-win.

There are a few things I really like in the code review process, and I consider as highly useful:

1. Ensure that the code is properly linted 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 promote consistent coding standards across the project. If the developers work actively and process it before the submission, it can greatly improve the whole review.

2. Encourage developers to review their code themselves before sharing it with you, as it helps catch basic issues like console logs, bad formatting, etc.

The developer should do this on the platform, before sharing a link with the reviewer. That usually helps with some unnecessary comments, console.logs, bad formatting and other leftovers.

3. Request a description of what changes have been made in the pull request. It provides context to the reviewer.

It doesn’t have to be extra detailed, but something like “Add a new page for players listing with table, the table has a pagination but cannot be sortable or filterable. For now, we have to use a mock for data as the API is not ready yet.” will show the overall context over-engineered code.

4. Consider attaching screenshots of the work done to aid the reviewer.

Sometimes it’s also good to send some screenshots, so the reviewer doesn’t have to run the project (unless he has to test it too).

Extra: Avoid creating pull requests with a large number of files. Smaller, focused pull requests are easier to review and provide more actionable feedback.

More files = fewer comments, as nobody is going to check that very precisely – it will take ages. If you have a big feature – you can create a branch for it and then create smaller sub-branches with smaller features.

These few things are just an example, and I would like to encourage you to set up your own rules the way you want.

GENERAL THINGS TO CONSIDER FOR CONDUCTING A REACT CODE REVIEW

Working in the same React team
If you are a React developer, and you are working on the same project with the developer requesting code review – you will both get some value from the code review process.

As a reviewer, you will see what is changing in the project, and you can immediately catch up from the code. This familiarity allows you to readily catch potential bugs in functional components, address backward compatibility issues, or rectify any incorrect usage of methods before they escalate into more significant challenges.

What’s more, you can share interesting code examples from this project with the team and share the knowledge.

Working outside the React team
On the other hand, if you are just responsible for the code review, but don’t work with the project itself – don’t feel sorry for the things you are not aware of. Nobody is going to blame you for functionality or code structure that is not working, and you didn’t notice it.

In general, it’s hard to find bugs during that process, and if you will find any – that’s great! But be ready to ask for more details or why some child components are done in this or that way and not the other. Get truly curious.

Making comments visible
Ensuring that comments are visible to everyone involved in the code review process helps maintain transparency and allows others to understand the context of discussions. It prevents the loss of important and constructive feedback and promotes a more inclusive and constructive code review experience.

Indicating the time
If you don’t have time for a proper code review – add it as a note.

Example: “I had only 15 minutes, so I just quickly checked the most important things like A, B, C.”.

Remember – if a person asks you for a review, tell them when you will have time for it. Even some of the good React developers have the tendency to just wait until you will finish the review and send them the code back.

If you tell them, that, for example, you will do it the next day – they may find some other work to do in the meantime.

Don’t waste time on styling issues
Generally, most of the comments in React code reviews (I’ve seen) are about styling issues – and personally, I don’t like them.

If you encounter styling concerns throughout the React codebase, address them once, and propose solutions to prevent their recurrence in the future.

This approach ensures a smoother review process and avoids repetitive comments on each request.

18 TIPS FOR A BETTER REACT CODE REVIEW

1. Check if there are any new npm packages added.

2. Check if there is no functionality duplicates like date-fns + moment.

3. Also check for imports, as sometimes tree shaking is not working as you wish, and you could bundle the whole library and use just a single method like the below:
   

import _ from 'lodash';
//should became more precise import like:
import uniq from 'lodash/uniq'; 

1. If your app is using translations – check if all new areas have also translations. 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>
  )
}

1. 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>
  )
}

1. *Check for variables, functions, and naming conventions.
   * They should all declare what they are and what they do.

2. *For boolean values, use prefixes is/are/should to declare their behaviour *(visible => isVisible) to avoid treating them as HTML properties.

3. Ensure functions declare their purpose, and if they return anything, name them accordingly. For example, if they manipulate data: updateUsers => addUniqId, parseData => parseToAPIFormat, etc.

4. Check for weird logic patterns (things you have never seen before). Sometimes when a React developer takes too much time on a single task – they start to be really creative while writing code and create methods or flow that have no sense at all and can destroy the project structure. You should provide feedback and suggest more suitable solutions to provide a better code.

5. Check for too complicated code chunks. If someone is adding an ID into an array using 20 lines of code instead of 1, take some actions. Or when you are using some 3rd party packages like lodash, but the developer keeps writing all the methods by himself.

6. If you can’t understand what a specific chunk of code is doing, **add descriptive comments to clarify its purpose. **Alternatively, request an explanation from the developer to avoid future confusion.

7. Check for hardcoded names, paths, and values. Separate that kind of code, so you can easily change it in one place. Use paths instead. They are (in most cases) used in routing configuration and in every link and redirection. Also, separate types, date formats and everything that can be used in multiple places – to easily change them.

8. Check for backward compatibility issues like changes in props from optional to required. Or changes in some methods’ parameter types. If you made such a change with TypeScript – it should throw a compilation error. If you are using just JavaScript – you need to track that manually.

9. Check for code repetition. If you’ve seen the same/similar logic in multiple places – point that out. Code should be reusable and if you will need to update that logic, you will have to update it in a single place. Not 3 of them.

10. Check for missing form validations or incorrect form validations. I’ve never seen React apps that have a form without field validation.

11. Check for missing error handlers from API responses to provide appropriate feedback to users. Pay attention to try/catch blocks and their handling in catch.

12. Check for async methods – can they be done in parallel, or do we need all the data in a sequence? Check if we actually wait for this data if we need it, or if we read from the promise object.

13. Sometimes you may notice potential bugs. A big part of knowledge comes with experience. If you are a good React developer and see something you’ve done in the past, but it caused errors – don’t make it happen again. Explain that you’ve been there, and you know the way out as you’ve made it work before.

COMMENTS IN REACT CODE REVIEW

I think that a good way of segregating the comments is to categorize them.

For example, divide them into at least 3 groups:

MAJOR – Comments that have a big impact on the code. They can break the react app, create potential issues, don’t meet the criteria, have regression issues, etc. They are just comments that have to be fixed before merging.

MINOR – In here we have some improvements – how we can write better code and build future-proof products. Mostly about changing the implementation to a more readable code, more reusable or just better but won’t affect functionality (mostly) :). But if the developer has a good explanation about why it should stay this way – it’s fine to skip these.

OPTIONAL – just syntax updates or something that won’t change the functionality at all. Like formatting issues or micro improvements.

Remember to communicate with your developer about the comments. That will speed up the process a lot.

Sometimes a simple “Hi, I left a few comments in your PR, please let me know if you have any necessary comments or questions.” is enough.

SUMMARY

Remember – even if 10 people will review your code, it’s still your code, and you are responsible for it.

Setting up some rules will make cooperation much easier.

Don’t forget to point out good things too.

If you think that something is wrong, and you have an idea how to fix it – suggest that – that will speed the process up.

Don’t just add comments like “change A to B” – add a proper explanation of why it should be changed. For example: “Please change the name from “changeUserStatus” to “changeUserData” as we are changing multiple fields in user – not just status.”

And of course, be nice! There is no point in making the developer feel guilty, sad or worthless. Using correct language will change the sentence meaning like “A to B” – “Can you change the name of A to B as it will be more readable”. In other words, give a reason for each change.

Also, remember to communicate about the process status, whenever you want to discuss some solution, or you need some more answers.

Did I miss anything? Let me know in the comments section!