For the past six months I have been watching the development of novice React programmers. During this time, they went just an incredible way. The speed of their training, their thirst for knowledge, their desire for excellence - all this made a strong impression on me.

How did they do it? How did they turn from those who cannot open PR without assistance to those whom others turn to for help? What made people asking for advice people willingly giving advice to others? How did students turn into teachers?

ITKarma picture

I asked them these questions. That's what they answered.

1. Use ESLint and TypeScript


JavaScript is a weakly typed programming language. Using this language, we can solve the same problem in countless ways. JavaScript does not have built-in mechanisms to protect us from writing code that contains errors or code that has poor performance. But, fortunately for us, we can improve the situation by resorting to two tools for static code analysis. These are TypeScript and ESLint.

Using ESLint for static code analysis, we can identify problems before they get into production. We can check the code against our standards. This improves codebase support.

For example, you can install the ESLint plugin CDMY0CDMY. This plugin will notice a problem in the following code, seemingly completely normal, and let us know that we are violating one of the rules use of hooks.

//мы нарушаем первое правило, используя хук в условии   if (userName !== '') {     useEffect(function persistForm() {       localStorage.setItem('formData', userName);     });   } 

TypeScript allows you to use a static type system to catch the corresponding errors. With TypeScript, you can use IntelliSense's powerful hint system, which speeds up and simplifies working with various components and libraries. The hints that appear during the process of writing code contain information about the internal mechanisms of components and libraries. This speeds up refactoring and promotes code writing conventions, such as using generics.

Anyone who is good at TypeScript not only becomes a more skilled JavaScript programmer, but also, as a result, begins to write better React code.

2. Get to know the React hooks


React hooks, since their introduction in February 2019, have literally taken over the world of React development. Although the React team says that you shouldn’t refactor old code by translating it into hooks, hooks are found everywhere nowadays.

If you want to advance in the field of React-development, then the best thing you can allocate time for is a deep study of hooks in order to fully understand them.

Do you need some kind of side effect? If so, then the CDMY1CDMY hook is your best friend. Do you need to monitor the state of a component and re-render it when the state changes? Take a look at CDMY2CDMY. It is necessary to store and update certain values ​​between renderings, but, if these values ​​change, do not render? Or maybe you need to know about the height or width of the DOM elements? Then your friend is CDMY3CDMY.

For example, let's look at the simplest example of using CDMY4CDMY. Suppose we want to organize an update to the page title (in the form of a side effect) by clicking on the button. You can try to solve this problem like this:

useEffect(() => {   document.title=`You clicked ${count} times`; });//запускается при каждом рендеринге 

This hook is easy to optimize by making it run not at every render, but only when the CDMY5CDMY variable changes. This is done by including CDMY6CDMY in the dependency array:

useEffect(() => {   document.title=`You clicked ${count} times`; }, [count]);//Эффект запускается только при изменении count 

It should be convenient for you to use the most common hooks and create your own hooks. You, in addition, should be well versed in the rational use of hooks. For example, to know when using hooks like CDMY7CDMY results in re-rendering, and when not.

3.Don't optimize your code too soon


Talking about hooks leads us to the topic of premature optimization. Too often I have seen how new React developers are prepared to die with bones in order to make their code as fast as possible. React code is most often optimized using the CDMY8CDMY and CDMY9CDMY hooks. But their use is not always justified.

Take a look at a simple component that accepts an array of confectionery information in the form of CDMY10CDMY. The component filters the array and displays a list of the names of chocolates (their property CDMY11CDMY is equal to the string value CDMY12CDMY).

Some developers may have an irresistible urge to write code that resembles the one shown below. They might think like this: "I will update the list of chocolates only when changing the general list of confectionery products." The implementation of this idea will lead to the appearance of code that is overloaded with auxiliary constructions, which is difficult to read.

const Chocolate=(props) => {   const chocolates=useMemo(     () => props.candies.filter((candy) => candy.type === "chocolate"),     [props.candies]   );   return (     <>       {chocolates.map((item) => (         <p>{item.name}</p>       ))}     </>   ); }; 

Instead of creating such a component, I would advise you to write simple and clean code. In cases like this, there is no reason to use CDMY13CDMY. The CDMY14CDMY or CDMY15CDMY hooks should be used only to memoize the results of complex operations that create a large load on the system.

I recommend postponing the start of optimization work until you get application performance measurements that clearly indicate a problem.

You should not use CDMY16CDMY and CDMY17CDMY everywhere just because you recently read about them somewhere. Do not optimize everything. It’s better to wait for the problem to appear, and then solve it. Do not solve non-existent problems.

4. Know when to create new components


I saw many beginner React programmers who implement the business logic of the project in components that should play an exclusively presentation role. In order to make your code as reusable as possible, it is important to create components that will be reusable as easily and conveniently as possible.

In order to achieve this, you need to strive to maintain the separation between presentation components and components that implement some kind of logic. Previously, it was common to divide components into “containers” and, in fact, “components”. But this approach has gradually lost relevance.

Take a look at a component that loads a list of elements from somewhere and displays them on a page. Please note that both of these tasks are implemented in the same component.

const ListItems=() => {   const items=React.useState([]);   React.useEffect(() => {     async function fetchItems() {       await fetched=fetchItems();       setItems(fetched);     }   }); return (     <>       {items.map((item) => (         <div className="item-container">           <img src={item.img}/>           <div className="name">{item.name}</div>           <div className="author">{item.author}</div>         </div>       ))}     </>   ); }; 

There may be a temptation to go the way of using the "container". Following this aspiration, we will come to the creation of two components:

const ListContainer=() => {   const items=React.useState([]);   React.useEffect(() => {     async function fetchItems() {       await fetched=fetchItems();       setItems(fetched);     }   }); return <List items={items}/>; }; const List=(props) => {   return (     <>       {props.items.map((item) => (         <div className="item-container">           <img src={item.img}/>           <div className="name">{item.name}</div>           <div className="author">{item.author}</div>         </div>       ))}     </>   ); }; 

But in a similar situation, one should do otherwise. Namely, it is necessary to abstract those parts of the component that play an exclusively presentation role. The result is two components - component CDMY18CDMY (list) and component CDMY19CDMY (element):

const List=() => {   const items=React.useState([]);   React.useEffect(() => {     async function fetchItems() {       await fetched=fetchItems();       setItems(fetched);     }   }); return (     <>       {items.map((item) => (         <Item item={item}/>       ))}     </>   ); }; const Item=({ item }) => {   return (     <div className="item-container">       <img src={item.img}/>       <div className="name">{item.name}</div>       <div className="author">{item.author}</div>     </div>   ); }; 

5. Pay particular attention to testing


A level of proficiency in testing technology is what separates juniors from seniors. If you are not familiar with the methods of testing React applications, you can find and study a lot of materials about this.

You may have written some unit tests once, but your experience is not enough to create integration tests covering the whole application? This should not bother you, since, again, there are countless resources that will help you fill in the knowledge gaps and build on the experience you need.

Here , for example, my material on the full cycle of testing a full stack application Based on React.

6. Distinguish situations in which to use local and global state


Here we will cover the topic of managing application state in React. There are many technologies to solve this problem. For example, these are redux, mobx, recoil, the CDMY20CDMY API, and much more. They are not easy to even list.

But, regardless of which state management technology is chosen, I often see React juniors get confused when deciding whether to use global or local state. Unfortunately, there are no clear rules to make such decisions unambiguously. But some rules regarding this issue can still be formulated. Namely, in order to decide whether to use the global or local state for storing certain data, answer the following questions:

  • Is it necessary that some component not directly connected to our component could work with its data? For example, a username can be displayed in the navigation bar and on the welcome screen.
  • Should data be saved when moving between pages of the application?
  • Are the same data used in multiple components?

If you can give positive answers to these questions, then perhaps you should take advantage of the global state. But, I’ll say right away that you should not store information about what is happening with the menu in a global state. When deciding where exactly to store certain data, try to speculate about what data is used in different places of the application, and about what data can be stored only inside the components.

Summary


Now you know what paths to take in order to professionally grow in the field of React-development.

When I recall the code that I wrote when I was a React Junior, one thing comes to mind. I wrote an overcomplicated code that was hard to understand. As I gained experience, I began to notice how my code became easier. The simpler the code, the better. My code is now easy to understand, and you can understand it even six months after writing it, when it turns out that an error has crept into it that needs to be understood.

And what paths to professional growth for React-programmers are known to you?

ITKarma picture.

Source