Новости и обновления в Telegram
rutube
Полезные видео о фронтенде. Подпишись на Rutube

Доступ к данным через рефы в React

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

Если вы хотите, чтобы React компонент «запоминал» некоторую информацию, но вы не хотите, чтобы эта информация запускала новые рендеры, вы можете использовать ref (рефы)

Содержание туториала по React Если вы хотите, чтобы компонент «запоминал» некоторую информацию, но вы не хотите, чтобы эта информация запускала новые рендеры, вы можете использовать ref (рефы).

Добавление рефа в компонент

Вы можете добавить реф в свой компонент, импортировав хук useRef из React: 
import { useRef } from 'react';
Внутри вашего компонента вызовите хук useRef и передайте начальное значение, на которое вы хотите сослаться, в качестве единственного аргумента. Например, вот ссылка на значение 0: 
const ref = useRef(0);
useRef возвращает такой объект: 
{
  current: 0; // Значение, отправленное в useRef
}
Вы можете получить доступ к текущему значению этого рефа через свойство ref.current. Это значение является изменяемым, то есть вы можете как читать, так и писать в него. Это как секретный карман вашего компонента, который React не отслеживает. (Вот что делает его лозейкой из одностороннего потока данных React — подробнее об этом ниже) В примере ниже кнопка будет увеличивать ref.current при каждом нажатии: 
import { useRef } from 'react';

export default function Counter() {
  let ref = useRef(0);

  function handleClick() {
    ref.current = ref.current + 1;
    alert('You clicked ' + ref.current + ' times!');
  }

  return <button onClick={handleClick}>Click me!</button>;
}
Реф указывает на число, но, как и состояние, вы можете указать что угодно: строку, объект или даже функцию. В отличие от состояния, ref — это простой объект JavaScript со свойством current, которое вы можете читать и изменять. Обратите внимание, что компонент не перерисовывается при очередном инкременте. Как и состояние, React сохраняет рефы между повторными рендерингами. Однако установка состояния повторно рендерит компонент. А изменение рефа - нет.

Пример: создание секундомера

Вы можете комбинировать рефы и состояние в одном компоненте. Например, давайте создадим секундомер, который пользователь может запускать или останавливать нажатием кнопки. Чтобы отобразить, сколько времени прошло с тех пор, как пользователь нажал «Старт», вам нужно будет отслеживать, когда была нажата кнопка «Старт» и какое сейчас время. Эта информация используется для рендеринга, поэтому вы сохраните ее в состоянии: 
const [startTime, setStartTime] = useState(null);
const [now, setNow] = useState(null);
Когда пользователь нажимает «Старт», вы будете использовать setInterval для обновления времени каждые 10 миллисекунд: 
import { useState } from 'react';

export default function Stopwatch() {
  const [startTime, setStartTime] = useState(null);
  const [now, setNow] = useState(null);

  function handleStart() {
    // Начало отсчета
    setStartTime(Date.now());
    setNow(Date.now());

    setInterval(() => {
      // Обновление текущего времени каждые 10 мс
      setNow(Date.now());
    }, 10);
  }

  let secondsPassed = 0;
  if (startTime != null && now != null) {
    secondsPassed = (now - startTime) / 1000;
  }

  return (
    <>
      <h1>Time passed: {secondsPassed.toFixed(3)}</h1>
      <button onClick={handleStart}>Start</button>
    </>
  );
}
 При нажатии кнопки «Стоп» нужно отменить существующий интервал, чтобы он перестал обновлять переменную состояния now. Вы можете сделать это, вызвав clearInterval, но вам нужно указать идентификатор интервала, который ранее возвращался вызовом setInterval, когда пользователь нажимал «Старт». Вам нужно где-то хранить идентификатор интервала. Поскольку идентификатор интервала не используется для рендеринга, вы можете сохранить его в рефе: 
import { useState, useRef } from 'react';

export default function Stopwatch() {
  const [startTime, setStartTime] = useState(null);
  const [now, setNow] = useState(null);
  const intervalRef = useRef(null);

  function handleStart() {
    setStartTime(Date.now());
    setNow(Date.now());

    clearInterval(intervalRef.current);
    intervalRef.current = setInterval(() => {
      setNow(Date.now());
    }, 10);
  }

  function handleStop() {
    clearInterval(intervalRef.current);
  }

  let secondsPassed = 0;
  if (startTime != null && now != null) {
    secondsPassed = (now - startTime) / 1000;
  }

  return (
    <>
      <h1>Time passed: {secondsPassed.toFixed(3)}</h1>
      <button onClick={handleStart}>Start</button>
      <button onClick={handleStop}>Stop</button>
    </>
  );
}
Когда информация используется для рендеринга - держите ее в состоянии. Когда информации нужна только обработчикам событий и ее изменение не требует повторного рендеринга - использование ссылки может быть более эффективным.

Различия между рефами и состоянием

Возможно, вы думаете, что рефы кажутся менее «строгими», чем состояние. Например, вы можете изменить их вместо того, чтобы постоянно использовать функцию установки состояния. Но в большинстве случаев вы захотите использовать состояние. Рефы — это лозейка, которая вам часто не потреюуется. Сравним состояние и рефы:
РефыСостояние
useRef(initialValue) возвращает { current: initialValue }useState(initialValue) возвращает текущее значение переменной состояния и функцию установки состояния ([value, setValue])
Не запускает повторный рендеринг при его изменении.Запускает повторный рендеринг при его изменении.
Изменяемый — вы можете изменять и обновлять значение current вне процесса рендеринга.Неизменный (иммутабельный) — вы должны использовать функцию установки состояния, чтобы изменить переменные состояния, чтобы поставить в очередь повторный рендеринг.
Вы не должны читать (или записывать) значение current во время рендеринга.Вы можете прочитать состояние в любое время. Однако каждый рендер имеет свой собственный снимок состояния, который не меняется.
Вот кнопка-счетчик, реализованная с состоянием: 
import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);

  function handleClick() {
    setCount(count + 1);
  }

  return <button onClick={handleClick}>You clicked {count} times</button>;
}
Поскольку отображается значение count, имеет смысл использовать для него значение состояния. Когда значение счетчика устанавливается с помощью setCount(), React повторно отображает компонент, и экран обновляется, чтобы отразить новое значение счетчика. Если вы попытаетесь реализовать это с помощью ref, React никогда не будет повторно отображать компонент, поэтому вы никогда не увидите изменения счетчика. Посмотрите, как нажатие на эту кнопку не обновляет ее текст: 
import { useRef } from 'react';

export default function Counter() {
  let countRef = useRef(0);

  function handleClick() {
    // В таком случае ререндеринг компонента Не происходит
    countRef.current = countRef.current + 1;
  }

  return (
    <button onClick={handleClick}>You clicked {countRef.current} times</button>
  );
}
Вот почему чтение ref.current во время рендеринга приводит к ненадежному коду. Если вам это нужно, используйте вместо этого состояние.

Как работает useRef внутри?

Хотя и useState, и useRef предоставляются React, в принципе useRef может быть реализован поверх useState. Вы можете представить, что внутри React useRef реализован так: 
// Внутри React
function useRef(initialValue) {
  const [ref, unused] = useState({ current: initialValue });
  return ref;
}
Во время первого рендеринга useRef возвращает { current: initialValue }. Этот объект хранится в React, поэтому при следующем рендеринге будет возвращен тот же объект. Обратите внимание, что в этом примере не используется установщик состояния. В этом нет необходимости, потому что useRef всегда должен возвращать один и тот же объект. React предоставляет встроенную версию useRef, потому что она достаточно распространена на практике. Но вы можете думать об этом как об обычной переменной состояния без сеттера. Если вы знакомы с объектно-ориентированным программированием, рефы могут напомнить вам поля экземпляра, но вместо this.something вы пишете somethingRef.current.

Когда использовать рефы?

Как правило, вы будете использовать рефы, когда вашему компоненту нужно «выйти за пределы» React и взаимодействовать с внешними API — часто API браузера, который не повлияет на внешний вид компонента. Вот несколько таких редких ситуаций:
  • Хранение других объектов, которые не нужны для вычисления JSX.
Если вашему компоненту нужно хранить какое-то значение, но это не влияет на логику рендеринга, выбирайте реф.

Рекомендации по использованию рефов

Следование этим принципам сделает ваши компоненты более предсказуемыми:
  • Относитесь к рефам как к лозейке. Рефы полезны при работе с внешними системами или API-интерфейсами браузера. Если большая часть логики вашего приложения и потока данных зависит от рефов, возможно, следует пересмотреть свой подход.
  • Не читайте и не записывайте ref.current во время рендеринга. Если во время рендеринга требуется некоторая информация, используйте вместо этого состояние. Поскольку React не знает, когда изменяется ref.current, даже его чтение во время рендеринга затрудняет прогнозирование поведения вашего компонента. (Единственным исключением является такой код, как if (!ref.current) ref.current = new Thing(), который устанавливает ссылку только один раз во время первого рендеринга.)
Ограничения состояния React не распространяются на ссылки. Например, состояние действует как снимок для каждого рендеринга и не обновляется синхронно. Но когда вы изменяете текущее значение ref, оно немедленно меняется: 
ref.current = 5;
console.log(ref.current); // 5
Это связано с тем, что сам реф является обычным JavaScript объектом и ведет себя как объект. Вам также не нужно беспокоиться о том, чтобы избежать мутации, когда вы работаете с рефами. Пока объект, который вы мутируете, не используется для рендеринга, React не волнует, что вы делаете с рефом или его содержимым.

Рефы и DOM

Вы можете указать ссылку на любое значение. Однако наиболее распространенным вариантом использования ссылки является доступ к элементу DOM. Например, это удобно, если вы хотите сфокусировать инпут программно. Когда вы передаете реф в атрибут ref в JSX, например <div ref={myRef}>, React поместит соответствующий элемент DOM в myRef.current.

Резюме

  • Рефы — это лозейка для хранения значений, которые не используются для рендеринга. Вы не будете нуждаться в них часто.
  • Ссылка — это простой объект JavaScript с одним свойством, называемым current, которое вы можете прочитать или установить.
  • Вы можете попросить React дать вам реф, вызвав хук useRef.
  • Как и состояние, рефы позволяют сохранять информацию между повторными рендерингами компонента.
  • В отличие от состояния, установка значения current рефа не вызывает повторный рендеринг.
  • Не читайте и не записывайте ref.current во время рендеринга. Это затрудняет прогнозирование вашего компонента.
FrontendReactТуториал по React

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. Во многих случаях речь идет о том, что подходит вам и вашей команде, а не о том, что конкретно считается "лучшей практикой". Именно разработчики, которые впоследствии будут редактировать и читать ваш код, должны будут уметь расшифровывать и улучшать ваш проект.
FrontendReactАрхитектура
logo

itdevjournal