Unetway

ReactJS - Строгий режим (Strict Mode)

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
  • Обнаружение неожиданных побочных эффектов
  • Дополнительные функциональные возможности будут добавлены к будущим выпускам React.

Определение опасных жизненных циклов

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

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

Предупреждение о унаследованном струнном использовании ссылок API

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

React 16.3 добавила третий вариант, который предлагает удобство строки 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();
  }
}

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

Заметка:

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

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

Концептуально, Реакт работает в два этапа:

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

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

Render фазы lifecycles включают следующие методы класса компонентов:

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

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

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

  • Классный компонентный constructorметод
  • renderметод
  • setState функции обновления (первый аргумент)
  • Статический getDerivedStateFromProps жизненный цикл

Заметка:

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

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

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

    SharedApplicationState.recordEvent('ExampleComponent');
  }
}

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

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