Состояние как снимок в React
год назад·5 мин. на чтение
Переменные состояния могут выглядеть как обычные переменные JavaScript, которые вы можете читать и записывать. Однако состояние в React больше похоже на снимок. Его установка не изменяет уже имеющуюся у вас переменную состояния, а вместо этого запускает повторный рендеринг.
Содержание туториала по React
Переменные состояния могут выглядеть как обычные переменные JavaScript, которые вы можете читать и записывать. Однако состояние больше похоже на снимок. Его установка не изменяет уже имеющуюся у вас переменную состояния, а вместо этого запускает повторный рендеринг.
Вот небольшой эксперимент, чтобы показать вам, как это работает. В этом примере вы можете ожидать, что нажатие кнопки «+3» увеличит счетчик на три, потому что он вызывается
Вот что обработчик нажатия этой кнопки сообщает React:
Вот пример того, как это делает ваши обработчики событий менее подверженными ошибкам синхронизации. Ниже представлена форма, которая отправляет сообщение с пятисекундной задержкой. Представьте себе этот сценарий:
Установка состояния запускает рендеринг
Вы можете думать о своем пользовательском интерфейсе как об изменении непосредственно в ответ на пользовательское событие, такое как клик. В React это работает немного иначе, чем эта ментальная модель. На предыдущей странице вы видели, что изменение состояния запрашивает повторный рендеринг. Это означает, что для того, чтобы интерфейс отреагировал на событие, вам необходимо обновить состояние. В этом примере, когда вы нажимаете "send",setIsSent(true)
сообщает React повторно отобразить пользовательский интерфейс:
Вот что происходит, когда вы нажимаете кнопку:import { useState } from 'react'; export default function Form() { const [isSent, setIsSent] = useState(false); const [message, setMessage] = useState('Hi!'); if (isSent) { return <h1>Your message is on its way!</h1>; } return ( <form onSubmit={(e) => { e.preventDefault(); setIsSent(true); sendMessage(message); }} > <textarea placeholder="Message" value={message} onChange={(e) => setMessage(e.target.value)} /> <button type="submit">Send</button> </form> ); } function sendMessage(message) { // ... }
- Выполняется обработчик события
onSubmit
. setIsSent(true)
устанавливаетisSent
вtrue
и кладет в очередь новый рендеринг.- React повторно отображает компонент в соответствии с новым значением
isSent
.
Рендеринг делает снимок во времени
"Рендеринг" означает, что React вызывает ваш компонент, который является функцией. JSX, который вы возвращаете из этой функции, подобен снимку пользовательского интерфейса в момент времени. Его пропсы, обработчики событий и локальные переменные были рассчитаны с использованием его состояния во время рендеринга. В отличие от фотографии или кадра фильма, "снимок" пользовательского интерфейса, который вы возвращаете, является интерактивным. Он включает в себя логику, такую как обработчики событий, которые определяют, что происходит в ответ на входные данные. Затем React обновляет экран в соответствии с этим снимком и подключает обработчики событий. В результате нажатие кнопки вызовет обработчик кликов из вашего JSX. Когда React перерисовывает компонент:- React снова вызывает вашу функцию.
- Ваша функция возвращает новый снимок JSX.
- Затем React обновляет экран в соответствии со снимком, который вы вернули.
setNumber(number + 1)
три раза.
Посмотрите, что происходит, когда вы нажимаете кнопку «+3»:
Обратите внимание, чтоimport { useState } from 'react'; export default function Counter() { const [number, setNumber] = useState(0); return ( <> <h1>{number}</h1> <button onClick={() => { setNumber(number + 1); setNumber(number + 1); setNumber(number + 1); }} > +3 </button> </> ); }
number
увеличивается только один раз за клик!
Установка состояния изменяет его только для следующего рендера. Во время первого рендера number
было 0
. Вот почему в обработчике этого рендеринга onClick
значение number
по-прежнему остается 0
даже после вызова setNumber(number + 1)
:
<button onClick={() => { setNumber(number + 1); setNumber(number + 1); setNumber(number + 1); }} > +3 </button>
setNumber(number + 1)
:number
равно0
таким образомsetNumber(0 + 1)
.- React готовится изменить
number
на1
в следующем рендеринге.
- React готовится изменить
setNumber(number + 1)
:number
равно0
таким образомsetNumber(0 + 1)
.- React готовится изменить
number
на1
в следующем рендеринге.
- React готовится изменить
setNumber(number + 1)
:number
равно0
таким образомsetNumber(0 + 1)
.- React готовится изменить
number
на1
в следующем рендеринге.
- React готовится изменить
setNumber(number + 1)
три раза, в этом рендере обработчик событий number
всегда равен 0
, поэтому вы устанавливаете состояние 1
три раза. Вот почему после завершения обработчика событий React повторно отображает компонент с number
равным 1
, а не 3
.
Вы также можете визуализировать это, мысленно заменяя переменные состояния их значениями в своем коде. Поскольку number
переменная состояния равна 0
для этого рендера, его обработчик событий выглядит так:
Для следующего рендера<button onClick={() => { setNumber(0 + 1); setNumber(0 + 1); setNumber(0 + 1); }} > +3 </button>
number
равен 1
, так что обработчик клика этого рендера выглядит так:
Вот почему повторное нажатие на кнопку установит счетчик на<button onClick={() => { setNumber(1 + 1); setNumber(1 + 1); setNumber(1 + 1); }} > +3 </button>
2
, затем 3
на следующий клик и т.д.
Состояние с течением времени
Попробуйте угадать, какое сообщение будет выведено вalert
при нажатии этой кнопки:
Если вы используете метод замены из предыдущего, вы можете догадаться, что предупреждение покажетimport { useState } from 'react'; export default function Counter() { const [number, setNumber] = useState(0); return ( <> <h1>{number}</h1> <button onClick={() => { setNumber(number + 5); alert(number); }} > +5 </button> </> ); }
0
:
Но что, если положитеsetNumber(0 + 5); alert(0);
alert
в таймер, чтобы оно срабатывало только после повторного рендеринга компонента? Будет ли он показывать 0
или 5
?
Если вы используете метод подстановки, вы можете увидеть «снимок» состояния, переданного вimport { useState } from 'react'; export default function Counter() { const [number, setNumber] = useState(0); return ( <> <h1>{number}</h1> <button onClick={() => { setNumber(number + 5); setTimeout(() => { alert(number); }, 3000); }} > +5 </button> </> ); }
alert
.
Состояние, хранящееся в React, могло измениться к моменту запуска оповещения, но оно было запланировано с использованием снимка состояния на момент взаимодействия с ним пользователя. Значение переменной состояния никогда не изменяется в процессе рендеринга, даже если код обработчика событий является асинхронным. ВнутриsetNumber(0 + 5); setTimeout(() => { alert(0); }, 3000);
onClick
этого рендера значение number
продолжает оставаться 0
даже после вызова setNumber(number + 5)
. Его значение было «фиксировано», когда React «сделал снимок» пользовательского интерфейса, вызвав ваш компонент.
- Вы нажимаете кнопку «Отправить», отправляя «Привет» Алисе.
- Прежде чем закончится пятисекундная задержка, вы измените значение поля «Кому» на «Боб».
alert
? Будет ли он отображать «Вы поздоровались с Алисой»? Или он будет отображать «Вы поздоровались с Бобом»? Сделайте предположение, основанное на том, что вы знаете:
React сохраняет значения состояния «фиксированными» в обработчиках событий одного рендеринга. Вам не нужно беспокоиться о том, изменилось ли состояние во время выполнения кода. Но что, если вы хотите прочитать последнее состояние перед повторным рендерингом? Вы захотите использовать функцию обновления состояния, описанную на следующей странице.import { useState } from 'react'; export default function Form() { const [to, setTo] = useState('Alice'); const [message, setMessage] = useState('Hello'); function handleSubmit(e) { e.preventDefault(); setTimeout(() => { alert(`You said ${message} to ${to}`); }, 5000); } return ( <form onSubmit={handleSubmit}> <label> To:{' '} <select value={to} onChange={(e) => setTo(e.target.value)}> <option value="Alice">Alice</option> <option value="Bob">Bob</option> </select> </label> <textarea placeholder="Message" value={message} onChange={(e) => setMessage(e.target.value)} /> <button type="submit">Send</button> </form> ); }
Резюме
- Состояние установки запрашивает новый рендеринг.
- React хранит состояние вне вашего компонента, как на полке.
- Когда вы вызываете
useState
, React дает вам снимок состояния для этого рендеринга . - Переменные и обработчики событий не «выживают» при повторном рендеринге. Каждый рендер имеет свои обработчики событий.
- Каждый рендер (и функции внутри него) всегда будет «видеть» снимок состояния, которое React дал этому рендеру.
- Вы можете мысленно заменить состояние в обработчиках событий, подобно тому, как вы думаете об отрендеренном JSX.
- Обработчики событий, созданные в прошлом, имеют значения состояния из рендеринга, в котором они были созданы.
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, хуки и тесты.
Как и прежде, способ настройки проекта зависит от вашего приложения и от того, как вы хотите его реализовать. Основная структура здесь зависит от типа файла и не более того. В конечном итоге структура вашего файла должна быть сделана так, чтобы в ней было легко ориентироваться. Как вы это сделаете, зависит только от вас. О других вариантах структурирования React приложения читайте в: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
2. Компоненты и разделение ответственности
До появления React Hooks было довольно легко определить, что считается компонентом класса с состоянием, а что - презентационным функциональным компонентом. Некоторые разработчики также называли их "умными" компонентами и "глупыми" компонентами. Разумеется, умные компоненты - это те, которые несут состояние и обрабатывают логику, а глупые компоненты - это те, которые просто принимают передаваемые им пропсы. После появления React Hooks и обновления Context API почти все можно считать функциональным компонентом, что приводит к разговору о том, когда следует разделять компоненты, содержащие локальное состояние, и компоненты, которые его не содержат, и как это делать. В конечном счете, это зависит от вас и/или вашей команды, как построить ваш паттерн проектирования, но лучшая практика показывает, что логика и компоненты с локальным состоянием должны быть отделены от статических компонентов. Подробнее о разделении ответственности читайте в статье Разделение ответственности в React. Как использовать контейнерные и презентационные компоненты..3. Работа с состоянием и пропсами
Поток данных в React-приложении очень важен. Есть два способа работы с данными: использование состояния или передача состояния в виде пропсов. Давайте рассмотрим лучшие практики.Состояние
При работе с состоянием, будь то глобально в контекстном API или локально, его нельзя изменять напрямую, переназначая свойство state с новым значением:Вместо этого при работе с состоянием в классовых компонентах используйте методaddOne = () => { // Так обновлять состояние нельзя this.state.counter += 1; }
this.setState()
для обновления состояния.
При использовании React Hooks вы будете использовать любое название своего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;
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 в настоящее время является более простым и предпочтительным способом). Подробнее о вариантах передачи данных между реакт компонентами читайте в статье Как передавать данные между компонентами в ReactJS4. Абстракция
React процветает благодаря возможности повторного использования. Когда мы говорим о лучших практиках React, часто встречается термин абстракция. Абстракция означает, что есть части большого компонента или приложения, которые могут быть изъяты, превращены в собственный функциональный компонент, а затем импортированы в более крупный компонент. Если сделать компонент как можно проще, часто так, чтобы он служил только одной цели, это увеличивает шансы на многократное использование кода. В простом приложении счетчика, созданном выше, есть возможность абстрагировать некоторые элементы от компонентаApp
. Кнопки могут быть абстрагированы в собственный компонент, где мы передаем метод и метку кнопки в качестве пропсов.
Заголовок и название приложения также могут быть размещены в собственных компонентах. После того как мы абстрагировали все элементы, компонент 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> ); }
5. Соглашения об именовании
В React есть три основных соглашения об именовании, которые следует рассматривать как лучшие практики.- Компоненты должны быть написаны в PascalCase - а также и названы по их основной функциональности, а не по специфике приложения (на случай, если вы измените ее позже).
- Элементы, которым нужны ключи, должны быть уникальными, неслучайными идентификаторами (например, отдельные карты или записи в карточной колоде или списке). Лучшая практика - не использовать для ключей только индексы. Допустимо назначение ключа, состоящего из конкатенации двух различных свойств объекта.
key={button.operation + button.buttonLabel}
- Методы должны быть в camelCase и называться по их назначению, а не быть специфичными для приложения. По тем же причинам, что и компоненты в PascalCase, методы должны быть названы по их назначению, а не по их особенности в приложении.