Как использовать переменные среды в React

Если у вас нет опыта server side программирования, переменные среды могут показаться чем-то магическим. Этот недостаток знаний может поставить вас в тупик, когда вы закончите создавать приложения todo на localhost и попытаетесь создать продакшн сборку в первый раз. Если вы хотите узнать, как использовать переменные среды в ваших собственных инструментах, или глубоко погрузиться в то, как переменные среды работают в React, вы можете продолжить чтение этой статьи. Но если вы ищете быстрое решение и используете Create React App, ознакомьтесь с документацией здесь. Пользователи NextJS, ознакомьтесь с документацией здесь.

Проблема, которую мы решаем

Как объявить различные URL-адресов API для локальной разработки и для продакшн сборки.

Как решить эту проблему

Использовать переменные среды. При работе с React переменные среды — это переменные, доступные через глобальный объект process.env. Этот глобальный объект предоставляется вашей средой через NodeJS. И поскольку у нас нет NodeJS в браузере, нам понадобится webpack. В этой статье рассмотрим два способа установки и использования переменных среды для ваших React проектов с помощью webpack: с помощью скриптов npm и с помощью файла .env.

Способ 1: Использование скриптов npm для установки переменных среды

Во-первых, установите webpack и webpack-cli из npm:

npm install --save-dev webpack webpack-cli

Перейдите в файл package.json, проверьте поле scripts и найдите команды, которые запускают webpack. Вероятно, это будет выглядеть примерно так:

{
  // ...
  scripts: {
    "dev": "webpack --config webpack.config.dev.js",
    "build": "webpack --config webpack.config.build.js"
  }
}

Давайте добавим некоторые переменные окружения с флагом --env в scripts:

{
  // ...
  scripts: {
    "dev": "webpack --env.API_URL=http://localhost:8000 --config webpack.config.dev.js",
    "build": "webpack --env.API_URL=https://www.myapi.com --config webpack.config.build.js"
  }
}

Мы добавили --env.API_URL= часть в обоих скриптах. Теперь запустите команду npm run dev, перейдите к React компоненту и используйте process.env.API_URL:

const App = () => <h1>{process.env.API_URL}</h1>;

И тут проект должен сломаться.

Сломается он потому, что когда мы используем переменные окружения в клиентском коде, они на самом деле просто служат заполнителями, которые будут заменены при компиляции нашего кода. Проблема в том, что мы не сказали webpack скомпилировать эти переменные в реальные значения. Давайте сделаем это в нашем конфигурационном файле webpack с плагином DefinePlugin:

const webpack = require('webpack'); // DefinePlugin это часть webpack, поэтому это require обязателен

// возвращаем функцию из config файла
// переменная `env` будет просто объектом { API_URL: 'http://localhost:8000' }
// в ней будут содержаться все переменные среды, которые мы указали в package.json

module.exports = (env) => {
  // этот объект это сама конфигурация webpack
  return {
    plugins: [
      // добавим плагин в список плагинов
      new webpack.DefinePlugin({ `process.env.API_URL`: JSON.stringify(${env.API_URL}) })
    ]
  };
};

DefinePlugin требует, чтобы вы буквально определили свои «переменные среды». Вы также можете применить .reduce к переменным среды, чтобы получить объект:

module.exports = (env) => {
  // создаем объект из переменных среды
  const envKeys = Object.keys(env).reduce((prev, next) => {
    prev[`process.env.${next}`] = JSON.stringify(env[next]);
    return prev;
  }, {});

  return {
    plugins: [
      new webpack.DefinePlugin(envKeys)
    ]
  };
};

Если вы запустите команду сейчас, все скомпилируется, и ваш process.env.API_URL будет скомпилирован в правильный URL-адрес на основе переменной среды.

Способ 2: Использование файла .env для установки переменных среды

Вся идея здесь состоит в том, чтобы создать файл (называемый просто .env), заполненный переменными среды. Чтобы защитить пароли и другие значения переменных среды, добавьте файл .env в .gitignore. Фронтенд код будет ссылаться на одну и ту же переменную среды (process.env.API_URL) в обеих средах (при локальной разработке и на продакшене), но поскольку вы определили разные значения в своих .env, скомпилированные значения будут отличаться.

Создадим файл .env

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

API_URL=http://localhost:8000

Обработка файла .env

Теперь нам нужен какой-то способ обработки файлов и их содержимого. Для этого мы собираемся использовать популярный npm пакет под названием dotenv. Dotenv широко используется (create-react-app использует его). Он будет получать переменные из нашего файла .env и добавлять их в глобальный process.env.

$ npm install --save-dev dotenv

Добавление переменных в проект React

Есть одна проблема. Dotenv работает только на стороне сервера. А мы хотим использовать переменные среды на стороне клиента, на фронтенде. В данном случае мы разрабатываем клиентскую часть. И dotenv нужна какая-то среда для фактического хранения переменных. Здесь поможет Webpack. Воспользуемся плагином DefinePlugin в нашей webpack конфигурации:

const webpack = require('webpack');
const dotenv = require('dotenv');

module.exports = () => {
  // dotenv вернет объект с полем parsed 
  const env = dotenv.config().parsed;
  
  // сделаем reduce, чтобы сделать объект
  const envKeys = Object.keys(env).reduce((prev, next) => {
    prev[`process.env.${next}`] = JSON.stringify(env[next]);
    return prev;
  }, {});

  return {
    plugins: [
      new webpack.DefinePlugin(envKeys)
    ]
  };
};

При необходимости проверьте параметры конфигурации dotenv в документации на github. Вызов .config() в dotenv вернет объект со всеми переменными среды, установленными в вашем файле .env через поле parsed. Теперь давайте проверим наш React код:

const App = () => <h1>{process.env.API_URL}</h1>;

И это работает! Он показывает значение переменной среды API_URL, определенной в .env. Осталась только одна проблема: нам все еще нужно определить различные API_URL для локальной разработки и продакшена.

Различные переменные среды для разных сред

Вся идея состоит в том, чтобы создать разные файлы .env для разных сред и позволить webpack выбрать правильный файл .env в зависимости от активной среды. Поэтому создайте два файла в корневом каталоге проекта:

• .env (содержит все переменные среды для продакшн)
• .env.development (содержит все переменные среды для локальной разработки)

Чтобы было ясно: мы добавляем к имени файла .env сопоставление имени среды. Общепринятой практикой является использование исходного файла .env для продакшн сборки, поэтому мы не будем добавлять постфикс для продакшн .env .

Настройка активной среды с помощью scripts в package.json

Мы собираемся использовать scripts (как мы это делали в методе 1), чтобы установить текущую среду в нашем package.json:

{
  "scripts": {
    "dev": "webpack --env.ENVIRONMENT=development --config webpack.config.dev.js",
    "build": "webpack --env.ENVIRONMENT=production --config webpack.config.build.js"
  }
}

Так как мы определили нашу среду в нашем package.json, теперь она доступна в нашей конфигурации webpack. Следующим шагом будет переход к webpack конфигурации и дать ему использовать файл .env, принадлежащий активной среде. Как и раньше, мы используем dotenv, но теперь мы указываем пользовательский path в параметрах.

const webpack = require('webpack');
const dotenv = require('dotenv');
const fs = require('fs'); // для проверки существования файла
const path = require('path'); // для получения текущего пути

module.exports = (env) => {
  // получаем корневой путь (предполагаем, что webpack config лежит в корне проекта)
  const currentPath = path.join(__dirname);
  
  // путь по умолчанию (будет использован для продакшена - `.env`)
  const basePath = currentPath + '/.env';

  // склеиваем имя среды с именем файла для получения имени env файла
  const envPath = basePath + '.' + env.ENVIRONMENT;

  // проверяем существует ли env файл, если нет используем имя по умолчанию
  const finalPath = fs.existsSync(envPath) ? envPath : basePath;

  // устанавливаем параметр path в dotenv
  const fileEnv = dotenv.config({ path: finalPath }).parsed;
  
  // сделаем reduce, чтобы получить объект
  const envKeys = Object.keys(fileEnv).reduce((prev, next) => {
    prev[`process.env.${next}`] = JSON.stringify(fileEnv[next]);
    return prev;
  }, {});

  return {
    plugins: [
      new webpack.DefinePlugin(envKeys)
    ]
  };

Эта вся необходимая настройка, но вы можете создать больше .env файлов для большего количества сред (например, .env.staging) по аналогии.

React 18 включает в себя улучшения производительности «из коробки» путем использования более частых операций пакетной обработки по умолчанию, что устраняет необходимость вручную объединять обновления в коде приложения или библиотеки. Это функциональность, о которой большинству пользователей можно не думать. Однако она может быть актуальна для преподавателей и разработчиков библиотек.

Что такое пакетная обработка (batching)?

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

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    setCount(c => c + 1); // Пока не происходит повторное отображение
    setFlag(f => !f); // Пока не происходит повторное отображение
    // React перерисует только один раз в конце (это пакетная обработка!)
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

Это отлично для производительности, потому что это позволяет избежать ненужных повторных рендеров. Это также предотвращает отображение компонента в "незаконченном" состоянии, где была обновлена только одна переменная состояния, что может вызвать ошибки. Это может напомнить вам о том, как официант ресторана не бежит на кухню, когда вы выбираете первое блюдо, а ждет, пока вы закончите заказ. Однако, React не всегда одинаково объединял обновления. Например, если вам нужно загрузить данные, а затем обновить состояние в указанном выше handleClick, то React не будет объединять обновления и будет выполнять два независимых обновления. Это происходит потому, что React раньше выполнял пакетную обработку только во время события браузера (например, нажатия кнопки), а здесь мы обновляем состояние после обработки события (в callback-функции fetch):

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    fetchSomething().then(() => {
      // React 17 и более ранние НЕ объединяют эти обновления, потому что
      // они запускаются ПОСЛЕ события в callback-функции, а не ВО ВРЕМЯ события
      setCount(c => c + 1); // Вызывает повторное отображение
      setFlag(f => !f); // Вызывает повторный рендеринг
    });
  }

  return (
   <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

До React 18 мы объединяли обновления только в обработчиках событий React. Обновления внутри Promise, setTimeout, нативных обработчиков событий или любых других событий по умолчанию не объединялись в React.

Что такое автоматическая пакетная обработка?

Начиная с React 18 с использованием createRoot, все обновления будут автоматически объединяться, независимо от их происхождения. Это означает, что обновления внутри таймеров, Promise, нативных обработчиков событий или любых других событий будут объединяться так же, как и обновления внутри событий React. Мы ожидаем, что это приведет к уменьшению работы по отрисовке и, следовательно, к лучшей производительности в ваших приложениях:

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    fetchSomething().then(() => {
      // React 18 и позднее ОБЪЕДИНЯЕТ эти обновления:
      setCount(c => c + 1);
      setFlag(f => !f);
      // React перерисует только один раз в конце (это пакетная обработка!)
    });
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

Примечание: Ожидается, что вы начнете использовать createRoot вместе с переходом на React 18. React будет автоматически объединять обновления, независимо от того, где они происходят, так что это:

function handleClick() {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React перерисует только один раз в конце (это пакетная обработка!)
}
и равносильно этому:

setTimeout(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React перерисует только один раз в конце (это пакетная обработка!)
}, 1000);
и равносильно этому:

fetch(/*...*/).then(() => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React перерисует только один раз в конце (это пакетная обработка!)
})
и равносильно этому:

elm.addEventListener('click', () => {
  setCount(c => c + 1);
  setFlag(f => !f);
  // React перерисует только один раз в конце (это пакетная обработка!)
});

Примечание: React объединяет обновления только тогда, когда это обычно безопасно. Например, React гарантирует, что для каждого события, инициированного пользователем, такого как клик или нажатие клавиши, DOM полностью обновляется перед следующим событием. Это гарантирует, например, что форма, которая отключается при отправке, не может быть отправлена дважды.

Что, если я не хочу использовать пакетную обработку?

Обычно пакетная обработка безопасна, но некоторый код может зависеть от считывания чего-либо из DOM сразу после изменения состояния. Для таких случаев вы можете использовать ReactDOM.flushSync(), чтобы отключить пакетную обработку:

import { flushSync } from 'react-dom'; // Обратите внимание: react-dom, а не react

function handleClick() {
  flushSync(() => {
    setCounter(c => c + 1);
  });
  // React уже обновил DOM
  flushSync(() => {
    setFlag(f => !f);
  });
  // React уже обновил DOM
}

Подробнее в оригинальной статье на GitHub