Как использовать переменные среды в 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) по аналогии.

Сопровождаемость является важным аспектом любой системы. Он определяет, насколько легко система может быть обновлена. Система будет работать оптимально только в том случае, если все компоненты хорошо обслуживаются. Если ваш проект имеет хорошо поддерживаемую архитектуру, разработчики могут легко понять проект и внести точечные изменения, чтобы повысить производительность при одновременном сокращении циклов разработки, тестирования и выпуска. Архитектура проекта является ключевым фактором, определяющим простоту обслуживания компонентов проекта. Многоуровневая архитектура является одной из лучших архитектур для написания поддерживаемых компонентов для UI фреймворков, таких как React. Поэтому в этой статье мы обсудим, как использовать многоуровневую архитектуру для написания простых в обслуживании компонентов на React и каких ошибок следует избегать.

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

Многоуровневая архитектура — это шаблон проектирования программного обеспечения, который организует приложение на несколько уровней, каждый из которых имеет определенный набор обязанностей. Эти слои организованы иерархически, при этом уровни более высокого уровня полагаются на слои более низкого уровня. Большинство многоуровневых архитектур имеют три или четыре стандартных уровня. Каждый слой может быть разработан и протестирован независимо в многоуровневой архитектуре, и изменения в одном слое не влияют на другие. Такое разделение позволяет разработчикам создавать организованные, модульные и масштабируемые системы, которые легче поддерживать и обновлять. Кроме того, такой подход позволяет вносить изменения в приложение без необходимости переписывать большие участки кода, снижая риск внесения ошибок или нарушения существующей функциональности. Давайте рассмотрим трехуровневую архитектуру в качестве примера, чтобы увидеть, как она может улучшить процесс разработки.

Трехуровневая архитектура

Вот эти три основных слоя: Презентационный слой (уровень представления, presentation layer) Уровень бизнес-логики (business logic layer, BLL) Уровень доступа к данным (data access layer, DAL) Уровень представления управляет взаимодействием с пользователем и представляет данные пользователю. Этот слой может представлять собой форму веб-интерфейса, десктопного или мобильного приложения. Он взаимодействует с уровнем бизнес-логики для выполнения действий и извлечения данных. Уровень бизнес-логики отвечает за реализацию бизнес-правил и рабочих процессов приложения. Этот уровень должен быть полностью независимым от уровня представления и не иметь представления о пользовательском интерфейсе. Он должен содержать всю логику и алгоритмы приложения и взаимодействовать с уровнем доступа к данным для получения необходимых данных. Уровень доступа к данным отвечает за взаимодействие с источниками данных приложения. Этот уровень отвечает за извлечение и хранение данных и должен быть отделен от уровня бизнес-логики. Он должен включать весь код, связанный с доступом к базе данных, вызовами API и другими внешними источниками данных.

Как использовать трехуровневую архитектуру в React

Давайте теперь рассмотрим, как мы можем применить принцип многоуровневой архитектуры к нашим React приложениям.

Уровень доступа к данным

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

export default async function fetchData() {
  const response = fetch('https://jsonplaceholder.typicode.com/users/1').then(
    (res) => {
      if (res.ok) return res.json();
      return Promise.reject(res);
    }
  );
  return response;
}

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

Уровень бизнес-логики

Этот слой обычно реализуется в виде набора пользовательских хуков, которые можно повторно использовать в разных компонентах. Рассмотрим следующий пользовательский хук seUserData(), который используется для получения данных о пользователе.

import React from "react";
import fetchData from "../util/fetchData";

const useUserData = () => {
  const [userData, setUserData] = useState([]);
  useEffect(() => {
    fetchData()
      .then((data) => setUserData(data))
      .catch((res) => console.error(res.status));
  }, []);
  return [userData];
};

export default useUserData;

Как видите, здесь вызывается функция fetchData() из слоя доступа к данным. Чтобы сделать этот хук более переиспользуемым, передайте путь URL-адреса в качестве аргумента кастомному хуку и передайте его в функцию fetchData().

Презентационный слой

Уровень представления должен содержать все компоненты пользовательского интерфейса, отвечающие за отрисовку данных и реагирование на действия пользователя в приложении React. В этих компонентах не должно быть бизнес-логики или кода запроса данных. Взглянем на пример компонента UserProfile ниже.

import React from "react";
import useUserData from "./customHooks/useUserData";

const UserProfile = () => {
  const [userData] = useUserData();
  return (
    <div>
      {userData.id ? (
        <div>
          <ul> {userData.name} </ul>
          <ul> {userData.email} </ul>
        </div>
      ) : (
        <p>Loading data...</p>
      )}
    </div>
  );
}

export default UserProfile;

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

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

• Переусложнение — поддерживайте простую и масштабируемую архитектуру и отказывайтесь от использования подходов, которые не соответствуют шаблонам React, таких как подходы на основе наследования.
• Сильная связанность — когда слои плотно связаны, то заменить один, не затрагивая другие, может быть стать сложной задачей. Уменьшите связанность, используя соответствующие шаблоны и методы, такие как внедрение зависимостей и интерфейсы.
• Игнорирование производительности — при неправильной реализации многоуровневая архитектура может повлиять на производительность приложения. При оптимизации архитектуры для повышения производительности учитывайте такие факторы, как разделение кода, отложенная загрузка и кэширование.
• Плохие соглашения об именах — используйте четкие и согласованные соглашения об именах для слоев, компонентов и функций. В противном случае разработчикам будет сложно понять и поддерживать код в долгосрочной перспективе.
• Отсутствие тестирования — каждый слой должен быть тщательно протестирован, чтобы убедиться, что он работает должным образом. Неспособность протестировать каждый слой может привести к ошибкам и другим проблемам в приложении.
• Отсутствие связности — каждый слой должен иметь высокую степень связности. Связность относится к тому, насколько тесно связаны функции и обязанности внутри слоя. Низкая связность может привести к тому, что код будет трудно понять и поддерживать.

Итоги

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