Style Tips. How to write a readable React code

When a developer conducts a code review, he rarely has enough time to delve into each line: you have to quickly think through various situations in which this code may not work. When analyzing, there are several points to pay attention to quickly understand exactly how the code works. Nirmalya Ghosh saw a few tricks on how to make the javascript code more elegant when creating components using the React library. Although we have our own particularities of development at ESF, which you can read about in this article , we find some of the techniques described under the cut interesting. We read and discuss in the comments!

Always use Prop-types to describe the properties of your components.

Prop-types is a module for checking types of React-properties and similar objects in runtime mode. Prop-types checks the property passed to the component to match the desired type.

If the type of the property passed to the component does not match the description, a warning will appear in the browser console. In the example above, the console will issue the following warning:
')

"Warning: Failed prop type: Invalid prop `message` of type `string` supplied to `Hello`, expected `array` in Hello" 

From this message it follows that the message property of type string is passed to the Hello component, although an array is assumed.

Although if you don’t like to write propTypes for each component, it is possible to use TypeScript, which allows you to check the compatibility of components not during debugging, but directly when compiling a project. In the development of a unified frontal system, we use TypeScript, since the speed of feedback significantly reduces the cost of developing large projects.

Use displayName to determine the name of the component.

The displayName string is used in debug messages. If you have not used displayName in your components yet, be sure to try!

As a rule, when debugging code using the React developer tools extension, you see components in it, whose names are taken from the name of the function or class that describes the component. However, if you have two components with the same name (button, dropdown, etc.), then you will most likely have to rename one of them. Otherwise, you cannot distinguish between them.

displayName solves this problem - the component can be renamed by setting this property to it. In the example above, even though the class is called Component, in the React developer tool extension you will see the name Hello, because Hello is its displayName.
This technique is very useful for debugging, but it is often underestimated.

Also in production assemblies you may not see the name of the components in React DevTools, since all the names of the components are obfuscated. displayName allows you to display the name of the component and it will be easier for you to find the error even in the combat configuration.

Use linter to make it easier to check your code.

If you care about clean code, you should use linter to check it. Such tools help to unify the style of the code in your team: if you strictly follow the given rules, the code base will always be uniform.

For example, you can take the rule to use a semicolon at the end of a line. If the developers do not follow this rule, linter will display an error or warning message depending on your settings.

The most famous linter is ESLint , but you can use any other tool suitable for you.

Since projects on the EFS platform are developed in TypeScript, we use TSLint in our work, the checks of which are run at every Pull Request, which does not allow code that does not correspond to the code style command accepted in the main branch.

The first iteration is not always the best.

Many of you know this - the first iteration is not always the best. You should carefully check your original code and think about what you might have missed. One way to test is to use the excellent, but rarely used Test Driven Development (TDD) technique. Using this approach, the first iteration can be the best. Think about what you are going to do before you write the first line of code, and when you introduce a new functionality or correct a mistake, look at the changes made and think about how to improve them.

There are several types of testing in the Unified Frontal System Program: in addition to unit tests built on the karma + jasmine stack, we use regression testing with comparing screenshots built on gemini technology. As we develop large applications, we pay a lot of attention to integration testing. We will not disclose in detail who has relevant cases or examples, let's discuss in the comments.

The structure of the project should be clear

Splitting large functions into smaller functions allows you to reuse these functions. In addition, small functions are easier to test. To get rid of code duplication, duplicate pieces of code can be placed in special service files.

After creating several files with the code, look, they probably have lines that overlap. They can be placed in the service file, and then used in other files.

In addition, it is important to divide one file into many small ones. Analyzing one large file is always more difficult than several smaller ones. If you break the code into several small files, each of which contains its own logic, it will become easier to view these files.

Be very careful when you name files.

Another thing to remember: if you name your files according to the functionality they contain, it will help you and other developers to better understand what is actually happening in this file.

For example, dropdown.js is a good name, but it is too general, so using it for several files in one directory, for example, topDropdown.js, bottomDropdown.js, is a bad practice.

As a prefix in the file name, it is better to use the task that the code in the file should perform. For example, userDropdown.js, fileDropdown.js, etc.

Always write tests for your code.

The importance of this advice can not be overemphasized. After the development of new functionality, you hope that the code works - it can actually work. But most likely, there will be boundary conditions under which it will work incorrectly. Tests will help identify such cases.

Obviously, writing tests will increase development time, but at the same time it will help eliminate possible errors and save time in the future to find and correct them.
If you care about the quality of the application, take the time to write tests.

Do not abuse reception for error handling.

In React 16, an efficient way to handle errors appeared - Error Boundaries.
In fact, Error Boundaries are React components that catch errors in their child components and output replacement code (fallback UI) instead of the component that broke.
If the fallback code is present in your ErrorBoundary component, you can encapsulate your YourComponent component inside it:

 <ErrorBoundary> <YourComponent/> </ErrorBoundary> 

This is a great way to output backup code for your components in case of errors. However, it is not necessary to put all your components inside ErrorBoundary. You can place the ErrorBoundary component in only a few critical areas of the code .

In developing the EFS platform, we use Error Boundaries for centralized error handling. Each of the errors falls on a special REST-service, allowing subsequent analysis of errors made in the development of applications.

Check your code before sending.

Whether you are developing a new functionality or correcting errors, the likelihood of haste when sending changes and creating a pull request is high.

Often, the developer does not look at the changes made, and therefore does not see room for improvement, when it is reasonable to break large functions into smaller ones and divide the code into modules. The habit of analyzing your own code helps to improve its quality.

We specifically endured this advice in conclusion, since this is one of the most common mistakes that delays the review of the code. The developer who opened the pull request for the first time sees the overall picture of all the changes, after which he adds new commits to the branch instead of immediately checking his code before opening the pull request.

We hope that the tips described will help make your code better! We invite you to discuss in the comments.