Полезные видео о фронтенде. Подпишись на Rutube

Чистая архитектура в Node.js

год назад·10 мин. на чтение

Чистая архитектура (Clean Architecture) — это концепция разработки программного обеспечения, которая фокусируется на создании модульного и поддерживаемого кода. Архитектура позволяет разработчику создавать кодовую базу, которую легко понять, протестировать и расширить.

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

Выявление и решение проблем

При разработке приложений Node.js мы часто сталкиваемся с некоторыми проблемами, такими как дублирование кода, неорганизованная кодовая база и тесная связь (tight coupling). В следующем разделе мы используем простой пример приложения Node.js, которое извлекает данные из базы данных и возвращает их в качестве ответа JSON. Чистая архитектура предлагает решения этих проблем, делая упор на следующие принципы:

Разделение ответственности (Separation of Concerns, SoC)

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

// index.js - Плохой код!

const express = require('express')
const app = express()
const database = require('./database')

app.get('/users', async (req, res) => {
  try {
    const users = await database.getUsers()
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
})

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})

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

Вот как мы можем применить разделение ответственности к этому коду:

// index.js

const express = require('express')
const app = express()
const usersRouter = require('./routes/users')

app.use('/users', usersRouter)

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})

// routes/users.js

const express = require('express')
const router = express.Router()
const usersController = require('../controllers/users')

router.get('/', usersController.getUsers)

module.exports = router

// controllers/users.js

const database = require('../database')

async function getUsers(req, res) {
  try {
    const users = await database.getUsers()
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
}

module.exports = {
  getUsers,
}

В этом переработанном коде мы разделили задачи маршрутизации, контроллера и извлечения данных на три отдельных файла. Файл index.js отвечает за создание приложения Express и регистрацию маршрутов, файл routes/users.js отвечает за обработку маршрута /users и делегирование запроса usersController, а файл controllers/users.js отвечает за извлечение данных из базы данных и возврат ответа клиенту. Разделив эти задачи, мы можем достичь лучшей модульности и удобства сопровождения кода. Например, если мы хотим добавить больше маршрутов, мы можем создать новый файл в routes и зарегистрировать его в index.js без изменения существующего кода. Аналогичным образом, если мы хотим изменить способ извлечения данных из базы данных, мы можем изменить database.js файл без изменения маршрута или кода контроллера.

Инверсия зависимостей (Dependency Inversion, DI)

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

// index.js - Плохой код!

const express = require('express')
const app = express()

const usersController = require('./controllers/users')
app.get('/users', async (req, res) => {
  try {
    const users = await usersController.getUsers()
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
})

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})

// controllers/users.js

const database = require('../database')
async function getUsers() {
  try {
    const users = await database.getUsers()
    return users
  } catch (error) {
    throw new Error('Error retrieving users')
  }
}

module.exports = {
  getUsers,
}

В этом коде index.js напрямую зависит от модуля usersController, который в свою очередь напрямую зависит от модуля database. Это нарушает принцип инверсии зависимостей, поскольку высокоуровневые модули не должны зависеть от низкоуровневых модулей.

Вот как мы можем применить инверсию зависимостей к этому коду:

// index.js

const express = require('express')
const app = express()
const usersController = require('./controllers/users')
const database = require('./database')

app.get('/users', async (req, res) => {
  try {
    const users = await usersController.getUsers(database)
    res.json(users)
  } catch (error) {
    res.status(500).send('Internal Server Error')
  }
})

app.listen(3000, () => {
  console.log('Server is listening on port 3000')
})

// controllers/users.js

async function getUsers(database) {
  try {
    const users = await database.getUsers()
    return users
  } catch (error) {
    throw new Error('Error retrieving users')
  }
}

module.exports = {
  getUsers,
}

В этом переработанном коде мы применили Dependency Inversion, передав модуль database в качестве параметра функции getUsers в модуле usersController. Таким образом, высокоуровневый модуль index.js не зависит напрямую от низкоуровневого модуля database, но оба зависят от абстракции функции getUsers. Применяя инверсию зависимостей, мы можем добиться большей модульности, гибкости и тестируемости кода. Например, если мы хотим переключиться на другую реализацию базы данных, мы можем создать новый модуль, реализующий функцию getUsers, и передать ее в качестве getUsers в модуле usersController без изменения существующего кода. Точно так же мы можем легко имитировать модуль database для целей модульного тестирования.

Принцип единой ответственности (Single Responsibility Principle, SRP)

Каждый модуль или функция должны нести единую ответственность. Это помогает в создании кодовой базы, которую легко понять и поддерживать. Вот пример в Node.js который иллюстрирует принцип SRP:

// user.js - Плохой код!

class User {
  constructor(name, email, password) {
    this.name = name;
    this.email = email;
    this.password = password;
  }

  saveToDatabase() {
    await database.saveUser(user)
    .then(() => {
      res.status(200).send()
    })
    .catch(err => {
      res.status(400).send('Email Error')
    });
  }

  sendWelcomeEmail() {
    await mailService.send(user, 'Welcome')
    .then(() => {
      res.status(200).send()
    })
    .catch(err => {
        res.status(400).send('Email Error')
    });
  }
}

В этом примере у нас есть класс User, который имеет две обязанности:

Сохранение пользовательских данных в базе данных
Отправка приветственного электронного письма пользователю

Это нарушает принцип SRP, поскольку класс User имеет несколько причин для изменения. Например, если мы решим изменить способ сохранения пользовательских данных в базе данных, нам также придется изменить класс User, даже если это не связано с отправкой приветственного электронного письма.

Чтобы следовать принципу SRP, мы можем разделить эти обязанности на отдельные классы:

class User {
  constructor(name, email, password) {
    this.name = name;
    this.email = email;
    this.password = password;
  }
}

class UserRepository {
  saveToDatabase(user) {
    await database.saveUser(user)
    .then(() => {
      res.status(200).send()
    })
    .catch(err => {
      res.status(400).send('Email Error')
    });
  }
}

class EmailService {
  sendWelcomeEmail(user) {
      await mailService.send(user, 'Welcome')
      .then(() => {
        res.status(200).send()
      })
      .catch(err => {
        res.status(400).send('Email Error')
      });
    }
  }
}

Теперь у нас есть три класса, каждый из которых несет единую ответственность:

User: отвечает за представление пользователя.
UserRepository: отвечает за сохранение пользовательских данных в базе данных.
EmailService: отвечает за отправку приветственного электронного письма пользователю.

Разделив обязанности, мы сделали наш код более модульным и простым в обслуживании. Если нам нужно изменить способ сохранения пользовательских данных в базе данных, нам нужно только изменить класс UserRepository. Класс User и класс EmailService остаются неизменными.

Концепции и детальное проектирование

Чистая архитектура в Node.js основана на принципах чистой архитектуры, введенных Робертом С. Мартином (он же дядя Боб). В нем подчеркивается разделение ответственности, разъединение зависимостей и модульность. Цель состоит в том, чтобы создать кодовую базу, которую легко понять, протестировать и поддерживать. Основная идея Clean Architecture заключается в разделении приложения на разные слои, где каждый уровень несет определенную ответственность. Слои взаимодействуют друг с другом через четко определенные интерфейсы. Это позволяет легко модифицировать и тестировать приложение, не затрагивая другие части кодовой базы. Node.js — это популярная среда выполнения для создания веб-приложений. Он имеет обширную экосистему библиотек и фреймворков, которые можно использовать для реализации Clean Architecture. Вот некоторые из ключевых концепций чистой архитектуры в Node.js:

Уровень инфраструктуры (Infrastructure Layer)

Уровень инфраструктуры отвечает за обработку внешних зависимостей, таких как базы данных, API или файловая система. Он должен быть отделен от уровня домена, чтобы обеспечить легкое тестирование и модификацию. Уровень инфраструктуры должен реализовывать интерфейсы, определенные уровнем домена. В Node.js уровень инфраструктуры может быть реализован с помощью пакетов или модулей. Например, можно использовать популярный пакет Knex.js для обработки запросов к базе данных. Уровень инфраструктуры должен быть спроектирован так, чтобы быть подключаемым, что позволяет легко заменять внешние зависимости. Вот пример модуля инфраструктуры, реализующего адаптер базы данных:

const knex = require('knex');

class UserDatabase {
  constructor(config) {
    this.db = knex(config);
  }
  
  async getById(id) {
    const data = await this.db('users').where({ id }).first();
    return data ? User.create(data) : null;
  }
  
  async save(user) {
    const data = User.toData(user);
    const { id } = user;
    
    if (id) {
      await this.db('users').where({ id }).update(data);
    } else {
      const [newId] = await this.db('users').insert(data);
      user.id = newId;
    }
  }
}

Этот модуль предоставляет методы для получения пользователя по идентификатору и сохранения пользователя в базе данных с помощью библиотеки Knex.js.

Уровень представления (Presentation Layer)

Уровень представления отвечает за отображение выходных данных приложения для пользователя и обработку вводимых пользователем данных. Он должен быть отделен от прикладного уровня и уровня инфраструктуры. Уровень представления может быть реализован с помощью веб-фреймворков, таких как Express.js или Hapi.js. В Node.js уровень представления может быть реализован с помощью веб-фреймворков или модулей. Веб-фреймворки предоставляют мощный и гибкий способ реализации уровня представления и размещения всей логики вместе. Вот пример модуля презентации, реализующего REST API с помощью веб-платформы Express.js:

const express = require('express');
const bodyParser = require('body-parser');
const UserService = require('./services/user-service');
const UserDatabase = require('./infra/user-database');

const app = express();

app.use(bodyParser.json());

const userDatabase = new UserDatabase(config);
const userService = new UserService(userDatabase);

app.get('/users/:id', async (req, res) => {
  const { id } = req.params;
  try {
    const user = await userService.getUserById(id);
    res.json(user);
  } catch (error) {
    res.status(404).json({ error: error.message });
  }
});

app.put('/users/:id', async (req, res) => {
  const { id } = req.params;
  const { userData } = req.body;
  try {
    let user = await userService.getUserById(id);
    user = User.create({ ...user, ...userData });
    await userService.saveUser(user);
    res.json(user);
  } catch (error) {
    res.status(404).json({ error: error.message });
  }
});

Этот модуль создает приложение Express.js, настраивает пользовательскую службу и базу данных, а также предоставляет конечные точки REST API для получения и обновления пользовательских данных.

Прикладной уровень (Application Layer)

Прикладной уровень отвечает за оркестрацию взаимодействия между доменным уровнем и уровнем инфраструктуры. Он содержит варианты использования приложения, которые представляют взаимодействия между пользователем и системой. Прикладной уровень должен быть отделен от уровня домена и уровня инфраструктуры. В Node.js прикладной уровень может быть реализован с помощью классов или модулей. Классы обеспечивают четкое разделение ответственности и инкапсуляцию. Модули обеспечивают более простой подход к реализации прикладного уровня. Вот пример класса приложения, представляющего пользовательскую службу:

class UserService {
  constructor(userDatabase) {
    this.userDatabase = userDatabase;
  }
  
  async getUserById(id) {
    const user = await this.userDatabase.getById(id);
    if (!user) {
      throw new Error(`User not found with ID ${id}`);
    }
    return user;
  }
  
  async saveUser(user) {
    await this.userDatabase.save(user);
  }
}

Этот класс предоставляет методы для получения пользователя по идентификатору и сохранения пользователя с помощью модуля инфраструктуры UserDatabase.

Уровень домена (Domain (Enterprise) Layer)

Доменный уровень является сердцем приложения, содержащим бизнес-логику и правила. Он должен быть независим от каких-либо внешних библиотек или фреймворков, что упрощает его тестирование и изменение. Доменный уровень является наиболее важной частью приложения, и любые изменения должны вноситься с большой осторожностью. В Node.js, уровень домена может быть реализован с помощью классов или модулей. Классы обеспечивают четкое разделение ответственности, инкапсуляцию и возможность повторного использования. Модули, с другой стороны, обеспечивают более простой подход к реализации доменного уровня. Вот пример класса домена, представляющего сущность пользователя:

class User {
  constructor(id, name, email) {
    this.id = id;
    this.name = name;
    this.email = email;
  }
  
  changeName(name) {
    this.name = name;
  }
  
  changeEmail(email) {
    this.email = email;
  }
  
  static create(data) {
    const { id, name, email } = data;
    return new User(id, name, email);
  }
  
  static toData(user) {
    const { id, name, email } = user;
    return { id, name, email };
  }
}

Этот класс инкапсулирует пользовательские данные и предоставляет методы для изменения имени и адреса электронной почты пользователя.

Использование сторонних npm пакетов

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

Lodash

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

const users = [
  { name: 'Alice', age: 25 },
  { name: 'Bob', age: 30 },
  { name: 'Charlie', age: 35 },
];

const filteredUsers = users.filter(user => user.age >= 30);

Используя Lodash, вы можете вместо этого написать следующий код:

const _ = require('lodash');

const users = [
  { name: 'Alice', age: 25 },
  { name: 'Bob', age: 30 },
  { name: 'Charlie', age: 35 },
];

const filteredUsers = _.filter(users, user => user.age >= 30);

Этот код более лаконичный и легкий для чтения, а использование функции filter от Lodash дает понять, что делает код.

Moment.js или date-fns

Moment.js — это библиотека для синтаксического анализа, манипулирования и форматирования даты и времени. Используя Moment.js, можно избежать написания сложного кода манипуляции с датой и снизить вероятность ошибок. Например, рассмотрим следующий код для форматирования даты в виде строки:

const date = new Date();
const formattedDate = `${date.getFullYear()}-${date.getMonth() + 1}-${date.getDate()}`;

Используя Moment.js, вы можете вместо этого написать следующий код:

const moment = require('moment');
const date = new Date();
const formattedDate = moment(date).format('YYYY-MM-DD');

Этот код легче читать и поддерживать, а использование функции format от Moment.js дает понять, что делает код.

Winston

Winston — это библиотека логирования (журналирования), которая предоставляет множество функций для ведения журнала сообщений, включая различные уровни логов и настраиваемое форматирование. Используя Winston, вы можете избежать написания пользовательского кода ведения журнала и убедиться, что ваши журналы согласованы и легко читаются. Например, рассмотрим следующий код для регистрации сообщения:

console.log(`[${new Date().toISOString()}] INFO: User logged in`);

Используя Winston, вы можете вместо этого написать следующий код

const winston = require('winston');

const logger = winston.createLogger({
  level: 'info',
  format: winston.format.combine(
    winston.format.timestamp(),
    winston.format.printf(info => `[${info.timestamp}] ${info.level}: ${info.message}`)
  ),
  transports: [
    new winston.transports.Console(),
    new winston.transports.File({ filename: 'app.log' }),
  ],
});
logger.info('User logged in');

Этот код более настраиваемый и легко читаемый, а использование Winston дает понять, что делает код.

Итоги

Чистая архитектура — это мощная концепция, которая может помочь вам создать модульный и поддерживаемый код в проектах Node.js. Следуя принципам чистой архитектуры, можно создать кодовую базу, которую легко понять, протестировать и расширить. Можно также использовать сторонние пакеты и различные структуры папок для повышения чистоты кода. Реализация Clean Architecture в проектах Node.js может помочь вам избежать распространенных ошибок, таких как дублирование кода, неорганизованная кодовая база и тесная связь.

Backend NodeJS Архитектура

Архитектура современного React приложения

2 года назад·6 мин. на чтение

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

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

Компоненты

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

├── components
│   ├── common
│   │   └── button
│   │       ├── button.tsx
│   │       ├── button.stories.tsx
│   │       ├── button.spec.tsx
│   │       └── index.ts
│   └── signup-form
│       ├── signup-form.tsx
│       ├── signup-form.spec.tsx
│       └── index.ts

Ключевым моментом здесь является следующее: у нас есть папка components, содержащая все компоненты, которые используются в приложении более одного раза, поэтому мы собираемся исключить все специфические компоненты из этой папки. Почему? Просто потому, что смысл этой папки заключается в том, чтобы содержать логику многократного использования. Кнопка должна использоваться почти на каждой странице нашего приложения, поэтому и существует общая папка common. Для компонента signup-form происходит нечто иное. Почему? Предположим, что у нас есть две разные страницы (подробнее об этом позже) для входа и регистрации, компонент signup-form должен повторяться два раза, вот почему он помещен в папку components.

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

button
├── button.tsx
├── button.stories.tsx
├── button.spec.tsx
└── index.ts

Это потому, что ваше приложение в конечном итоге может содержать более 1000 компонентов, и, если все они имеют тесты или файл storybook, это может легко превратиться в беспорядок. Давайте рассмотрим некоторые ключевые моменты этой папки:

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

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

Где находится компонент кнопки? -> В папке button.
Где находятся сторибуки для этой кнопки? -> В папке button.
Мне нужно найти тесты для этой кнопки, где я могу его найти? -> Очевидно, в папке button.

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

Страницы

Отдельной сущности для страниц в React не существует. Они тоже являются компонентами, состоящими из других компонентов. Но в отличие от других компонентов, обычно они очень строго привязаны (например, в определенный путь URL). Куда же их вставлять? Мы можем использовать каталог views (или pages, если хотите), в который помещаются все эти вещи, например:

views
├── home.tsx
├── guestbook.tsx
└── newsletter
   ├── index.ts
   ├── newsletter.tsx
   └── components
       └── newsletter-form
           ├── newsletter-form.tsx
           ├── newsletter-form.spec.tsx
           └── index.ts

Для home и guestbook все довольно просто, страница должна быть результатом композиции других компонентов, которые имеют соответствующие тесты, поэтому для них нет специального каталога.

Иначе обстоит дело со страницей newsletter , на которой есть нечто специфическое, компонент newsletter-form. В этом случае используется подход создания вложенной папки компонентов внутри папки страницы и действуем так же, как в обычной папке компонентов, используя те же правила. Этот подход очень эффективен, поскольку позволяет разделить код на небольшие фрагменты, но при этом сохраняет хорошо организованную архитектуру. Компонент newsletter-form не следует помещать в папку с общими components, просто потому, что это единственное место, в котором он используется. Если приложение будет расти, и компонент будет использоваться в нескольких частях, ничто не помешает вам переместить его. Еще один совет - сохранять согласованное имя между страницей и маршрутом, примерно так:

<Route path="/bookings">
 <Route index element={<Bookings />} />
 <Route path="create" element={<CreateBooking />} />
 <Route path=":id" element={<ViewBooking />} />
 <Route path=":id/edit" element={<EditBooking />} />
 <Route path=":id/delete" element={<DeleteBooking />} />
</Route>

Лэйауты (Layouts, Макеты)

Лэйауты вообще не являются страницами, они больше похожи на компоненты, поэтому с ними можно обращаться так же, но лучше помещать их в папку layouts, так понятнее, что в этом приложении есть n лэйаутов.

layouts
├── main.tsx
└── auth.tsx

Вы можете заметить, что мы не называем их main-layout.tsx, а просто main.tsx, потому что, следуя этому шаблону, нам пришлось бы переименовать все компоненты, например, table-component.tsx, что странно. Поэтому называем все компоненты без очевидного суффикса, задаваемого родительским каталогом, а если нужно подчеркнуть, что используется макет, всегда можно использовать псевдоним импорта.

import { Main as MainLayout } from "@/layouts/main.tsx";

Контексты, хуки и хранилища

Это довольно просто, и обычно, почти все разработчики придерживаются чего-то подобного:

hooks
├── use-users.ts
└── use-click-outside.ts
contexts
├── workbench.tsx
└── authentication.tsx

Опять же, для единообразия используется kebab-case для всех имен файлов, так что нам нужно беспокоиться о том, какие из них написаны заглавными буквами, а какие нет. Для тестовых файлов, из-за того, что пользовательских хуков немного, не обязательно создавать отдельную папку, но, если вы хотите быть очень строгими, вы можете сделать и это:

hooks
├── use-users
│   ├── use-users.ts
│   ├── use-users.spec.ts
│   └── index.ts
└── use-click-outside.ts

Функции-помощники (хэлперы, helpers)

Сколько раз вы создавали красивую функцию formatCurrency, не зная, куда ее положить? Папка helpers придет вам на помощь. Обычно сюда помещаются все файлы, которые используются для того, чтобы код выглядел лучше. Не важно, будет ли функция использоваться несколько раз или нет.

helpers
├── format-currency.ts
├── uc-first.ts
└── pluck.ts

Константы

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

constants
└── index.ts

Кроме того, можно хранить все константы в одном файле. Нет смысла разбивать каждую константу на отдельные файлы.

// @/constants/index.ts
export const COMPLANY_EMAIL = "example@example.com";

И использоваться они будут так:

import { COMPLANY_EMAIL } from "@/constants";

Стили

Просто поместите глобальные стили в папку styles, и все готово.

styles
├── index.css
├── colors.css
└── typography.css

А как насчет CSS для компонентов? Хороший вопрос. Помните папку компонентов, о которой мы говорили некоторое время назад? Так вот, вы можете добавить больше файлов в зависимости от ваших потребностей.

button
├── button.tsx
├── button.stories.tsx
├── button.styled.tsx
├── button.module.scss
├── button.spec.tsx
└── index.ts

Если вы используете emotion, styled-components или просто CSS Modules, поместите их в папку конкретного компонента, чтобы все было оптимально упаковано.

Конфигурационные файлы

Есть ли у вашего приложения файлы конфигурации, такие как Dockerfiles, Fargate Task Definitions, webpack и т.д.? Папка config должна быть идеальным местом для них. Помещение их в соответствующую директорию позволяет избежать загрязнения корневого каталога не относящимися к делу файлами.

API

99% приложений react имеют хотя бы один вызов API к внешнему источнику данных (вашему бэкенду или какому-то публичному сервису), обычно эти операции выполняются в нескольких строках кода без особых сложностей, и именно поэтому, оптимальная их организация игнорируется. Рассмотрим этот код:

axios
 .get("https://api.service.com/bookings")
 .then((res) => setBookings(res.data))
 .catch((err) => setError(err.message));

Довольно просто, верно? Теперь представьте, что у вас есть эти 3 строки, распределенные по 10 компонентам, потому что вы часто используете именно этот адрес сервера. Надеюсь, вы не хотите выполнять поиск и замену всех URL в приложении, кроме того, если вы используете TypeScript, импортировать каждый раз тип ответа - это довольно повторяющееся действие.

Вместо этого рассмотрите возможность использования каталога api, который, прежде всего, содержит экземпляр клиента, используемого для вызовов, например, fetch или axios, а также файлы, содержащие декларации вызовов fetch.

api
├── client.ts
├── users.ts
└── bookings.ts

И пример файла users.ts:

export type User = {
 id: string;
 firstName: string;
 lastName: string;
 email: string;
};

export const fetchUsers = () => {
 return client.get<User[]>("/users", {
   baseURL: "https://api.service.com/v3/",
 });
};

Итоги

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

Frontend React Архитектура