Чистые компоненты в React

2 года назад·2 мин. на чтение

В этой статье рассмотрим чистые компоненты в функциональных компонентах ReactJS.

Чистый компонент в React — это компонент, который всегда рендерит одно и то же при одних и тех же значениях пропсов. Это серьезно улучшает производительность. React будет использовать результат последнего рендера, избегая повторного рендеринга.

React.memo

React.memo — это компонент высшего порядка (higher-order component, HOC). Когда компонент отображает тот же вывод при одних и тех же пропсах, вы можете обернуть свой функциональный компонент этой функцией React.memo. За счет этого улучшится производительность и оптимизируется рендеринг. React.memo работает только при изменении пропсов компонента. Это означает, что если вы используете состояние, используя хук useState, то для каждого изменения состояния он будет ререндерить компонент. С React.memo выполняется поверхностное сравнение пропсов.
Рассмотрим компонент CustomLabel и Counter, внутри которого используется CustomLabel.
// CustomLabel.jsx

import React from "react";

export const CustomLabel = ({ name }) => {
  return (
    <>
      {console.log("CustomLabel component render")}
      <label>
        <b>{name}</b>
      </label>
    </>
  );
};
// Counter.jsx

import React, { useState } from "react";
import CustomLabel from "./CustomLabel";

export const Counter = () => {
  const [counter, setCounter] = useState(0);

  return (
    <div>
      <CustomLabel name="Simple Counter app" />
      <p>Counter is: {counter}</p>
      <button onClick={() => setCounter(counter + 1)}>Click</button>
    </div>
  );
};
Компонент CustomLabel принимает name в качестве пропса и отображает его в теге label. В компонент CustomLabel мы добавили console.log(), чтобы мы могли видеть, сколько раз компонент ререндерится. Всякий раз, когда вы нажимаете кнопку, чтобы увеличить счетчик, он повторно рендерит компонент CustomLabel.
Теперь поработаем с React.memo. Обернем компонент CustomLabel в React.memo и снова будем нажимать счетчик. Увидим, что он отрендерил компонент CustomLabel только один раз, потому что проп name остается неизменным при каждом нажатии кнопки.
// CustomLabel.jsx

import React, {memo} from "react";

export const CustomLabel = memo(({ name }) => {
  return (
    <>
      {console.log("CustomLabel component render")}
      <label>
        <b>{name}</b>
      </label>
    </>
  );
});
Чистые компоненты названы так по аналогии с чистыми функциями.

Что такое чистые функции?

В Javascript функции, которые возвращают один и тот же вывод при одних и тех же входных данных, называются чистыми функциями. Таким образом, результат чистой функции зависит только от ее входных аргументов. Чистые функции также не вызывают никаких побочных эффектов. Рассмотрим чистую функцию add.
function Add(num1, num2){
  return num1 + num2;
}
Если мы вызовем вышеуказанную функцию add(2,2), она всегда будет возвращать 4. Если вызвать ее несколько раз с параметрами 2 и 2, она всегда будет возвращать 4. Благодаря тому что функция чистая можно оптимизировать и улучшить производительность приложения. Еще подробнее о чистых функциях можно прочитать в статье Чистые функции. Функциональное программирование.

5 лучших практик для React разработчиков

2 года назад·6 мин. на чтение

В этой статье мы рассмотрим пять наиболее распространенных лучших практик для React разработчиков. React был разработан для того, чтобы его можно было настроить именно так, как вам нужно - он не имеет жестких ограничений. Поэтому, если эти пять сценариев лучших практик вам не подходят, вы можете найти свой собственный подход.

Существует множество способов структурировать код так, чтобы он был читабельным, и у каждого свой подход к этому. Возникает вопрос, есть ли лучший способ сделать это? Мы поговорим о лучших практиках:
  • Организация каталога
  • Компоненты и разделение ответственности
  • Работа с состояниями
  • Абстракция
  • Соглашения об именовании

1. Организация каталогов

В документации React упоминается, что в целом существует два основных способа организации вашего приложения React: Группировка по функциям или маршрутам и Группировка по типу файлов. Главное здесь - не перемудрить. Если вы начинаете с небольшого приложения, вы можете органично организовать свой код по ходу работы так, как вам удобно. Помните, что React не имеет собственной жесткой структуры, поэтому на 100% зависит от вас, как все будет структурировано. Если у вас есть логическое объяснение тому, как организованы файлы, то все хорошо. Однако, поскольку в документации React упоминаются эти две стратегии организации, давайте рассмотрим каждую из них, чтобы понять, как они структурированы. Допустим, у нас есть приложение для электронной коммерции, в котором есть пользователь, список товаров, подробная страница товара, корзина и процесс оформления заказа.

Группировка по функциям

Корневой каталог здесь - это каталог src, который является одним из двух базовых каталогов в вашем приложении React (второй - папка public). В каталоге src у нас будут основные файлы App.js и index.js в корне папки. Затем у нас будут вложенные каталоги для каждой из функций вашего приложения. Ваш подход к структуре может варьироваться в зависимости от того, как все организовано: в проекте может быть больше каталогов, меньше каталогов или даже более глубокая вложенность на компоненты, стилизацию и тестирование.
src/
  App.js
  App.css
  App.test.js
  index.js
  global/ <= общие для всего приложения сущности
    AppContext.js
    ThemeContext.js
    UserContext.js
    Button.js
  cards/
    index.js
    Cards.css
    Cards.js
    Card.css
    Card.js
    Card.test.js
  detailed-product/
    DetailedProduct.css
    DetailedProduct.js
    DetailedProduct.test.js
  checkout/
    ReviewOrder.css
    ReviewOrder.js
    ReviewOrder.test.js
    ShoppingCart.css
    ShoppingCart.js
    ShoppingCart.test.js
  user/
    index.js
    User.css
    User.js
    User.test.js

Группировка по типу файлов

Корневой каталог по-прежнему является каталогом src. Все, что будет отображаться на экране клиента, по-прежнему находится в этой папке. Как и раньше, мы будем хранить файлы App.js и index.js в корне этого каталога, а затем каталоги, представляющие составные части приложения: компоненты, контекст, CSS, хуки и тесты.
src/
  App.js
  index.js
  components/
    App.css
    Card.js
    Cards.js
    ConfirmationPage.js
    DetailedProduct.js
    Footer.js
    Navbar.js
    ReviewOrder.js
    Settings.js
    ShoppingCart.js
    User.js
  context/
    AppContext.js
    ThemeContext.js
    UserContext.js
  css/
    Card.css
    Cards.css
    ConfirmationPage.css
    DetailedProduct.css
    Footer.css
    Navbar.css
    ReviewOrder.css
    Settings.css
    ShoppingCart.css
    User.css
  hooks/
    useAuth.js
    useAxios.js
  tests/
    App.test.js
    Card.test.js
    Cards.test.js
    ConfirmationPage.test.js
    DetailedProduct.test.js
    Footer.test.js
    Navbar.test.js
    ReviewOrder.test.js
    Settings.test.js
    ShoppingCart.test.js
    User.test.js
Как и прежде, способ настройки проекта зависит от вашего приложения и от того, как вы хотите его реализовать. Основная структура здесь зависит от типа файла и не более того. В конечном итоге структура вашего файла должна быть сделана так, чтобы в ней было легко ориентироваться. Как вы это сделаете, зависит только от вас. О других вариантах структурирования React приложения читайте в:

2. Компоненты и разделение ответственности

До появления React Hooks было довольно легко определить, что считается компонентом класса с состоянием, а что - презентационным функциональным компонентом. Некоторые разработчики также называли их "умными" компонентами и "глупыми" компонентами. Разумеется, умные компоненты - это те, которые несут состояние и обрабатывают логику, а глупые компоненты - это те, которые просто принимают передаваемые им пропсы. После появления React Hooks и обновления Context API почти все можно считать функциональным компонентом, что приводит к разговору о том, когда следует разделять компоненты, содержащие локальное состояние, и компоненты, которые его не содержат, и как это делать. В конечном счете, это зависит от вас и/или вашей команды, как построить ваш паттерн проектирования, но лучшая практика показывает, что логика и компоненты с локальным состоянием должны быть отделены от статических компонентов. Подробнее о разделении ответственности читайте в статье Разделение ответственности в React. Как использовать контейнерные и презентационные компоненты..

3. Работа с состоянием и пропсами

Поток данных в React-приложении очень важен. Есть два способа работы с данными: использование состояния или передача состояния в виде пропсов. Давайте рассмотрим лучшие практики.

Состояние

При работе с состоянием, будь то глобально в контекстном API или локально, его нельзя изменять напрямую, переназначая свойство state с новым значением:
addOne = () => { // Так обновлять состояние нельзя
  this.state.counter += 1;
}
Вместо этого при работе с состоянием в классовых компонентах используйте метод this.setState() для обновления состояния.
import React from "react";
import "./styles.css";
class Counter extends React.Component{
 constructor(props) {
   super(props);
   this.state = {
     counter: 0
   }
 }
 addOne = () => {
   this.setState({counter: this.state.counter + 1})
 }
 subtractOne = () => {
   this.setState({counter: this.state.counter - 1});
 }
 reset = () => {
   this.setState({ counter: 0 });
 }
 render() {
   return (
     <div className="App">
       <h1>Simple React Counter</h1>
       <h2>{this.state.counter}</h2>
       <button onClick={this.addOne}> + </button>
       <button onClick={this.reset}> Reset </button>
       <button onClick={this.subtractOne}> - </button>
     </div>
   );
 }
}
export default Counter;
При использовании React Hooks вы будете использовать любое название своего set метода:
import React, { useState } from "react";
import "./styles.css";
export default function App() {
 const [ counter, setCounter ] = useState(0);
 const addOne = () => {
   setCounter(counter + 1)
 }
 const subtractOne = () => {
   setCounter(counter - 1);
 }
 const reset = () => {
   setCounter(0);
 }
   return (
     <div className="App">
       <h1>Simple React Counter</h1>
       <h2>{counter}</h2>
       <button onClick={subtractOne}> - </button>
       <button onClick={reset}> Reset </button>
       <button onClick={addOne}> + </button>
     </div>
   );
}

Пропсы

При работе с пропсами и передаче состояния другим компонентам для использования, может наступить момент, когда вам потребуется передать пропсы пяти дочерним компонентам. Такой метод передачи пропсов от родителя к ребенку на протяжении нескольких поколений называется prop drilling, и его следует избегать. Хотя код, безусловно, будет работать, если вы будете передавать проп на много уровней вниз, он подвержен ошибкам, и поток данных может быть трудно отслеживать. Вам следует создать какой-либо паттерн проектирования для глобального управления состоянием с помощью Redux или Context API (Context API в настоящее время является более простым и предпочтительным способом). Подробнее о вариантах передачи данных между реакт компонентами читайте в статье Как передавать данные между компонентами в ReactJS

4. Абстракция

React процветает благодаря возможности повторного использования. Когда мы говорим о лучших практиках React, часто встречается термин абстракция. Абстракция означает, что есть части большого компонента или приложения, которые могут быть изъяты, превращены в собственный функциональный компонент, а затем импортированы в более крупный компонент. Если сделать компонент как можно проще, часто так, чтобы он служил только одной цели, это увеличивает шансы на многократное использование кода. В простом приложении счетчика, созданном выше, есть возможность абстрагировать некоторые элементы от компонента App. Кнопки могут быть абстрагированы в собственный компонент, где мы передаем метод и метку кнопки в качестве пропсов. Заголовок и название приложения также могут быть размещены в собственных компонентах. После того как мы абстрагировали все элементы, компонент App может выглядеть примерно так:
import React, { useState } from "react";
import { Button } from "./Button";
import { Display } from "./Display";
import { Header } from "./Header";
import "./styles.css";

export default function App() {
  const addOne = () => {
   setCounter(counter + 1)
 }
 const subtractOne = () => {
   setCounter(counter - 1);
 }
 const reset = () => {
   setCounter(0);
 }
 const initialState = [
   {operation: subtractOne, buttonLabel:"-"},
   {operation: reset, buttonLabel: "reset"},
   {operation: addOne, buttonLabel: "+"}
 ]
 const [ counter, setCounter ] = useState(0);
 const [ buttonContents,  ] = useState(initialState)
    return (
     <div className="App">
       <Header header="Simple React Counter"/>
       <Display counter={counter}/>
       {buttonContents.map(button => {
         return (
           <Button key={button.operation + button.buttonLabel} operation={button.operation} buttonLabel={button.buttonLabel} />
         )
       })}
     </div>
   );
}
Основная цель абстракции - сделать дочерние компоненты как можно более общими, чтобы их можно было использовать повторно в любом нужном вам виде. App-компонент должен содержать только ту информацию, которая специфична для приложения, и выводить или возвращать только более мелкие компоненты.

5. Соглашения об именовании

В React есть три основных соглашения об именовании, которые следует рассматривать как лучшие практики.
  1. Компоненты должны быть написаны в PascalCase - а также и названы по их основной функциональности, а не по специфике приложения (на случай, если вы измените ее позже).
  2. Элементы, которым нужны ключи, должны быть уникальными, неслучайными идентификаторами (например, отдельные карты или записи в карточной колоде или списке). Лучшая практика - не использовать для ключей только индексы. Допустимо назначение ключа, состоящего из конкатенации двух различных свойств объекта.
Основная цель ключа - хранить базовую информацию, чтобы React мог получить представление о том, что изменилось в приложении.
key={button.operation + button.buttonLabel}
  1. Методы должны быть в camelCase и называться по их назначению, а не быть специфичными для приложения. По тем же причинам, что и компоненты в PascalCase, методы должны быть названы по их назначению, а не по их особенности в приложении.

Итоги

В этой статье мы рассмотрели пять лучших практик, которые следует применять при разработке на React. Во многих случаях речь идет о том, что подходит вам и вашей команде, а не о том, что конкретно считается "лучшей практикой". Именно разработчики, которые впоследствии будут редактировать и читать ваш код, должны будут уметь расшифровывать и улучшать ваш проект.