Строгий режим

Последнее обновление: 31 июля 2019 г. 08:44:33 (UTC / GMT +8 часов)

script1adsense2code

script1adsense3code

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

Замечания:

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

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

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

В приведенном выше примере строгие проверки режима не будут выполняться для компонентов заголовка и нижнего колонтитула. Тем не менее, ComponentOne и ComponentTwo, а также все их потомки, будут иметь проверки. StrictMode в настоящее время помогает с:

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

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

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

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

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

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

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

В React 16.3 добавлена третья опция, которая обеспечивает удобство ссылки на строку без каких-либо недостатков:

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();
  }
}

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

Замечания:

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

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

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

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

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

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

Вы также можете добавить 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, а затем сравнивает результат с предыдущим render.
Фаза фиксации - это когда React применяет любые изменения. (В случае React DOM это когда React вставляет, обновляет и удаляет узлы DOM.) React также вызывает жизненные циклы, такие как componentDidMount и componentDidUpdate, на этом этапе.

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

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

конструктор
componentWillMount
componentWillReceiveProps
componentWillUpdate
getDerivedStateFromProps
shouldComponentUpdate
оказывать
Функции обновления setState (первый аргумент)

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

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

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

Замечания:

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

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

class TopLevelRoute extends React.Component {
  constructor(props) {
    super(props);
    SharedApplicationState.recordEvent('ExampleComponent');
  }
}

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

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