Жесткий режим

StrictMode — это инструмент для выделения потенциальных проблем в приложении. Как и Fragment, StrictMode не отображает какой-либо видимый пользовательский интерфейс. Он активирует дополнительные проверки и предупреждения для своих потомков.

Примечание:

Проверки строгого режима выполняются только в режиме разработки; они не влияют на сборку в режиме производства.

Вы можете включить строгий режим для любой части вашего приложения. Например:

import React from 'react';

function ExampleApplication() {
  return (
    <div>
      <Header />
      <React.StrictMode>
        <div>
          <ComponentOne />
          <ComponentTwo />
        </div>
      </React.StrictMode>
      <Footer />
    </div>
  );
}

В приведенном выше примере, проверки строгого режима не будут выполняться для компонентов Header и Footer. Однако, компоненты ComponentOne и ComponentTwo, а также все их потомки, будут иметь эти проверки.

StrictMode в настоящее время помогает с:

• Выявление компонентов с небезопасными жизненными циклами
• Предупреждение об использовании устаревшего API string ref
• Предупреждение об использовании устаревшего findDOMNode
• Обнаружение непредвиденных побочных эффектов
• Обнаружение устаревшего API контекста

Дополнительные функции будут добавлены в будущих выпусках React.

Выявление небезопасных жизненных циклов

Как объясняется в этом блоге, определенные устаревшие методы жизненного цикла небезопасны для использования в асинхронных приложениях React. Однако, если ваше приложение использует сторонние библиотеки, может быть сложно убедиться, что эти жизненные циклы не используются. К счастью, строгий режим может помочь в этом!

Когда строгий режим включен, React компилирует список всех компонентов класса, использующих небезопасные жизненные циклы, и выводит сообщение с предупреждением с информацией об этих компонентах, например:

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

Предупреждение об использовании устаревшего API string ref

Ранее React предоставлял два способа управления ссылками: устаревшее API string ref и API обратного вызова. Хотя API string ref был более удобным из двух, у него было несколько недостатков, поэтому наша официальная рекомендация заключалась в использовании варианта обратного вызова.

React 16.3 добавил третий вариант, предлагающий удобство string ref без каких-либо недостатков:

class MyComponent extends React.Component {
  constructor(props) {
    super(props);

    this.inputRef = React.createRef();
  }

  render() {
    return <input type="text" ref={this.inputRef} />;
  }

  componentDidMount() {
    this.inputRef.current.focus();
  }
}

Поскольку ссылки на объекты в основном добавлялись как замена string ref, строгий режим теперь предупреждает об использовании string ref.

Примечание:

Ссылки обратного вызова по-прежнему будут поддерживаться в дополнение к новому createRef API.

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

Дополнительную информацию о новом createRef API вы найдете здесь.

Предупреждение об использовании устаревшего findDOMNode

React раньше поддерживал findDOMNode для поиска узла DOM в дереве по заданному экземпляру класса. Обычно вам это не нужно, так как вы можете непосредственно прикрепить ссылку к узлу DOM.

findDOMNode также можно использовать с компонентами класса, но это нарушало уровни абстракции, позволяя родительскому элементу требовать определенного рендеринга дочерних элементов. Это создает риски рефакторинга, когда вы не можете изменить детали реализации компонента, потому что родительский элемент может обращаться к его узлу DOM. findDOMNode возвращает только первого потомка, но с использованием фрагментов возможно, что компонент может отображать несколько узлов DOM. findDOMNode — это API однократного чтения. Он давал вам ответ только тогда, когда вы его просили. Если дочерний компонент отображает другой узел, нет способа обработать это изменение. Поэтому findDOMNode работал только в том случае, если компоненты всегда возвращают один узел DOM, который никогда не меняется.

Вместо этого вы можете сделать это явно, передав ссылку на свой пользовательский компонент и передав её узлу DOM с помощью передачи ссылок.

Вы также можете добавить оберточный узел DOM в свой компонент и непосредственно прикрепить к нему ссылку.

class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.wrapper = React.createRef();
  }
  render() {
    return <div ref={this.wrapper}>{this.props.children}</div>;
  }
}

Примечание:

В CSS атрибут display: contents можно использовать, если вы не хотите, чтобы узел был частью макета.

Обнаружение непредвиденных побочных эффектов

Концептуально, React работает в двух фазах:

• Фаза рендеринга определяет изменения, которые необходимо внести в, например, DOM. В ходе этой фазы React вызывает render, а затем сравнивает результат с предыдущим рендерингом.
• Фаза коммита — это когда React применяет любые изменения. (В случае React DOM, это когда React вставляет, обновляет и удаляет узлы DOM.) React также вызывает жизненные циклы, такие как componentDidMount и componentDidUpdate на этой фазе.

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

Жизненные циклы фазы рендеринга включают следующие методы компонентов класса:

• constructor
• componentWillMount (или UNSAFE_componentWillMount)
• componentWillReceiveProps (или UNSAFE_componentWillReceiveProps)
• componentWillUpdate (или UNSAFE_componentWillUpdate)
• getDerivedStateFromProps
• shouldComponentUpdate
• render
• setState функции обновления (первый аргумент)

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

Строгий режим не может автоматически обнаруживать побочные эффекты, но он может помочь вам их определить, сделав их немного более детерминированными. Это делается путем преднамеренного двойного вызова следующих функций:

• Методы компонентов класса constructor, render, и shouldComponentUpdate
• Статический метод компонента класса getDerivedStateFromProps
• Тела компонентов функций
• Функции обновления состояния (первый аргумент для setState)
• Функции, переданные useState, useMemo, или useReducer

Примечание:

Это относится только к режиму разработки. Жизненные циклы не будут вызываться дважды в режиме производства.

Например, рассмотрим следующий код:

class TopLevelRoute extends React.Component {
  constructor(props) {
    super(props);

    SharedApplicationState.recordEvent('ExampleComponent');
  }
}

На первый взгляд, этот код может показаться не проблематичным. Но если SharedApplicationState.recordEvent не идемпотентна, то многократное создание этого компонента может привести к некорректной состоянию приложения. Этот вид скрытой ошибки может не проявляться во время разработки или проявляться непредсказуемо и, следовательно, быть упущенным из виду.

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

Примечание:

Начиная с React 17, React автоматически изменяет методы консоли, такие как console.log() для отключения записей при втором вызове функций жизненного цикла. Однако это может привести к нежелательному поведению в определенных случаях, где можно использовать обходной путь.

Обнаружение устаревшего API контекста

Устаревшее API контекста подвержено ошибкам и будет удалено в будущей основной версии. Оно всё ещё работает для всех версий 16.x, но в режиме строгого режима будет показано это сообщение с предупреждением:

Прочитайте документацию по новому API контекста, чтобы помочь в миграции на новую версию.