redrockjs/frontend-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

update state, api, arch

Browse Source
This commit is contained in:
Valery Grunenko
2025-03-07 14:17:37 +03:00
parent 7484909864
commit 8263e7507a
40 changed files with 1774 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

88
docs/api/01-http.md Normal file
View File

@@ -0,0 +1,88 @@
---
sidebar_position: 1
---
# Протокол HTTP
**HTTP (HyperText Transfer Protocol)** — это протокол прикладного уровня, используемый для передачи данных в сети Интернет. Он является основой для обмена информацией между клиентом (например, веб-браузером) и сервером (например, веб-сайтом). HTTP работает по модели "запрос-ответ": клиент отправляет запрос, а сервер возвращает ответ.
## Основные характеристики HTTP:
1. **Текстовый протокол:**
- HTTP использует текстовый формат для передачи данных, что делает его легко читаемым и отлаживаемым.
2. **Работает поверх TCP/IP:**
- HTTP использует TCP (Transmission Control Protocol) как транспортный протокол для установления соединения между клиентом и сервером.
3. **Статус ответа:**
- Сервер возвращает HTTP-коды состояния, которые указывают на результат выполнения запроса:
- `1xx` — информационные коды (например, `100 Continue`).
- `2xx` — успешные коды (например, `200 OK`, `201 Created`).
- `3xx` — коды перенаправления (например, `301 Moved Permanently`, `302 Found`).
- `4xx` — ошибки клиента (например, `400 Bad Request`, `404 Not Found`).
- `5xx` — ошибки сервера (например, `500 Internal Server Error`, `503 Service Unavailable`).
4. **Методы HTTP:**
- HTTP определяет набор методов (или "глаголов"), которые указывают, какое действие нужно выполнить:
- `GET` — запрос данных от сервера.
- `POST` — отправка данных на сервер для создания ресурса.
- `PUT` — обновление существующего ресурса.
- `DELETE` — удаление ресурса.
- `PATCH` — частичное обновление ресурса.
- `HEAD` — запрос заголовков ответа без тела.
- `OPTIONS` — запрос информации о поддерживаемых методах.
5. **Заголовки (Headers):**
- HTTP-заголовки содержат метаданные о запросе или ответе. Они могут включать информацию о типе содержимого, кэшировании, авторизации и т.д.
- Примеры заголовков:
- `Content-Type` — тип данных (например, `application/json`).
- `Authorization` — данные для аутентификации.
- `User-Agent` — информация о клиенте (например, браузере).
6. **Тело запроса/ответа (Body):**
- Тело содержит данные, которые передаются между клиентом и сервером. Например, в запросе `POST` тело может содержать данные для создания ресурса, а в ответе — данные запрошенного ресурса.
7. **Без состояния (Stateless):**
- Каждый HTTP-запрос обрабатывается независимо от других. Сервер не хранит информацию о предыдущих запросах от клиента.
## Пример HTTP-запроса и ответа:
**Запрос:**
```
GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html
```
**Ответ:**
```
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
<!DOCTYPE html>
<html>
<head>
<title>Example</title>
</head>
<body>
<h1>Hello, World!</h1>
</body>
</html>
```
## Версии HTTP:
1. **HTTP/1.0:**
- Первая версия, поддерживающая базовые функции.
2. **HTTP/1.1:**
- Наиболее распространенная версия, поддерживающая соединения `keep-alive`, который позволил загружать множество ресурсов в рамках одного соединения, кэширование и другие улучшения.
3. **HTTP/2:**
- Вторая версия, которая добавляет мультиплексирование, сжатие заголовков и другие оптимизации для повышения производительности.
4. **HTTP/3:**
- Новая версия, основанная на протоколе QUIC, которая улучшает скорость и безопасность.
## Где используется HTTP:
- Веб-сайты и веб-приложения.
- RESTful API.
- Мобильные приложения.
- Микросервисы.
## Безопасность:
- **HTTPS (HTTP Secure)** — это защищенная версия HTTP, которая использует шифрование TLS/SSL для защиты данных от перехвата и подделки.
HTTP является фундаментальным протоколом для работы в Интернете и используется практически во всех веб-технологиях.

5
docs/api/01-rest-api.md
View File

@@ -1,5 +0,0 @@
---
sidebar_position: 1
---
# REST API

5
docs/api/02-http.md
View File

@@ -1,5 +0,0 @@
---
sidebar_position: 2
---
# Протокол HTTP

39
docs/api/02-https.md Normal file
View File

@@ -0,0 +1,39 @@
---
sidebar_position: 2
---
# Протокол HTTPS
**HTTPS (HyperText Transfer Protocol Secure)** — это защищенная версия протокола HTTP, которая использует шифрование для безопасной передачи данных между клиентом и сервером. HTTPS обеспечивает конфиденциальность, целостность и аутентификацию данных.
## Основные особенности HTTPS:
1. **Шифрование:**
- Данные передаются в зашифрованном виде с использованием протоколов TLS (Transport Layer Security) или его предшественника SSL (Secure Sockets Layer).
- Это защищает информацию от перехвата и чтения третьими лицами.
2. **Аутентификация:**
- HTTPS использует SSL/TLS-сертификаты для подтверждения подлинности сервера. Это помогает клиенту убедиться, что он взаимодействует с настоящим сервером, а не с поддельным.
3. **Целостность данных:**
- HTTPS гарантирует, что данные не были изменены во время передачи.
4. **Порт по умолчанию:**
- HTTPS использует порт **443** (в отличие от HTTP, который использует порт 80).
5. **Использование:**
- HTTPS применяется для защиты конфиденциальных данных, таких как пароли, платежные реквизиты, персональная информация.
## Как работает HTTPS:
1. Клиент (например, браузер) запрашивает соединение с сервером.
2. Сервер отправляет свой SSL/TLS-сертификат, который содержит публичный ключ.
3. Клиент проверяет сертификат и использует публичный ключ для шифрования данных.
4. Устанавливается безопасное соединение, и данные передаются в зашифрованном виде.
## Преимущества HTTPS:
- **Безопасность:** Защита от перехвата данных.
- **Доверие:** Пользователи видят значок замка в адресной строке, что повышает доверие к сайту.
- **SEO:** Поисковые системы (например, Google) отдают предпочтение сайтам с HTTPS.
- **Соответствие стандартам:** HTTPS необходим для соблюдения современных требований безопасности (например, GDPR).
## Пример использования:
- Интернет-магазины (защита платежей).
- Банковские приложения.
- Социальные сети и почтовые сервисы.
HTTPS стал стандартом для современных веб-сайтов, обеспечивая безопасность и конфиденциальность пользователей.

5
docs/api/03-http-status.md
View File

@@ -1,5 +0,0 @@
---
sidebar_position: 3
---
# Статус ответа HTTP

53
docs/api/03-rest-api.md Normal file
View File

@@ -0,0 +1,53 @@
---
sidebar_position: 3
---
# REST API
**REST API** (Representational State Transfer Application Programming Interface) — это архитектурный стиль для создания веб-сервисов, который основывается на стандартных протоколах и методах HTTP. REST API используется для взаимодействия между клиентом и сервером, где клиент отправляет запросы, а сервер возвращает ответы в формате, обычно JSON или XML.
## Основные принципы REST API:
1. **Ресурсы (Resources):**
- Все данные рассматриваются как ресурсы, которые идентифицируются с помощью URL (например, `/users`, `/products`).
- Каждый ресурс имеет уникальный идентификатор (URI).
2. **HTTP-методы:**
- Используются стандартные HTTP-методы для выполнения операций:
- `GET` — получение данных.
- `POST` — создание нового ресурса.
- `PUT` — обновление существующего ресурса.
- `DELETE` — удаление ресурса.
- `PATCH` — частичное обновление ресурса.
3. **Статус ответа:**
- Сервер возвращает HTTP-коды состояния, которые указывают на результат выполнения запроса:
- `200 OK` — успешный запрос.
- `201 Created` — ресурс успешно создан.
- `400 Bad Request` — неверный запрос.
- `404 Not Found` — ресурс не найден.
- `500 Internal Server Error` — ошибка на сервере.
4. **Без состояния (Stateless):**
- Каждый запрос от клиента к серверу должен содержать всю необходимую информацию для его обработки. Сервер не хранит состояние клиента между запросами.
5. **Кэширование:**
- Ответы сервера могут быть кэшированы для повышения производительности.
6. **Единообразие интерфейса:**
- API должен быть простым и понятным, с использованием стандартных подходов.
7. **Форматы данных:**
- RESTful API обычно использует JSON или XML для передачи данных между клиентом и сервером.
## Пример REST API:
Предположим, у нас есть API для управления пользователями:
- `GET /users` — получить список всех пользователей.
- `GET /users/1` — получить информацию о пользователе с ID 1.
- `POST /users` — создать нового пользователя (тело запроса содержит данные пользователя).
- `PUT /users/1` — обновить информацию о пользователе с ID 1.
- `DELETE /users/1` — удалить пользователя с ID 1.
## Преимущества REST API:
- **Простота:** Использует стандартные HTTP-методы и статусы.
- **Масштабируемость:** Подходит для больших и распределенных систем.
- **Гибкость:** Поддерживает различные форматы данных (JSON, XML).
- **Кэширование:** Улучшает производительность за счет кэширования ответов.
- **Независимость от платформы:** Может использоваться с любым языком программирования или технологией.
## Разница между REST API и RESTful API:
- **REST API** — это общий термин, описывающий API, которое следует принципам REST.
- **RESTful API** — это более строгий термин, подразумевающий, что API полностью соответствует всем принципам REST.

56
docs/api/04-graphql.md Normal file
View File

@@ -0,0 +1,56 @@
---
sidebar_position: 4
---
# GraphQL
**GraphQL** — это язык запросов для API, который позволяет клиентам запрашивать только те данные, которые им нужны, и получать их в одном ответе. В сочетании с React GraphQL предоставляет мощный инструмент для управления данными в веб-приложениях, делая их более эффективными и гибкими.
## Основные концепции GraphQL:
1. **Запросы (Queries):**
- Клиент определяет, какие данные ему нужны, и отправляет запрос на сервер.
```js
query {
user(id: 1) {
name
email
posts {
title
}
}
}
```
2. **Мутации (Mutations):**
- Используются для изменения данных на сервере (создание, обновление, удаление).
```js
mutation {
createUser(name: "John", email: "john@example.com") {
id
name
}
}
```
3. **Схема (Schema):**
- GraphQL API описывается с помощью схемы, которая определяет типы данных и операции (запросы, мутации).
4. **Резолверы (Resolvers):**
- Функции на сервере, которые выполняют запросы и возвращают данные.
## Использование GraphQL с React:
Для работы с GraphQL в React чаще всего используется библиотека Apollo Client или Relay. Apollo Client — это популярное решение, которое предоставляет инструменты для управления состоянием данных и выполнения запросов.
### Основные шаги для использования GraphQL с React:
1. **Установка Apollo Client**
- Установите необходимые пакеты: `npm install @apollo/client graphql`
2. **Настройка Apollo Client:**
- Создайте клиент и подключите его к React-приложению: `<ApolloProvider client={client}> <App/> </ApolloProvider>`
3. **Выполнение запросов:**
- Используйте хуки useQuery для выполнения запросов и useMutation для мутаций.
4. **Кэширование данных:**
- Apollo Client автоматически кэширует данные, что позволяет избежать повторных запросов и улучшить производительность.
## Преимущества GraphQL с React:
- **Точные запросы:** Получайте только те данные, которые нужны.
- **Уменьшение количества запросов:** Все данные можно получить за один запрос.
- **Гибкость:** Легко изменять запросы без необходимости изменять API.
- **Интеграция с состоянием:** Apollo Client интегрируется с состоянием React, что упрощает управление данными.

5
docs/api/04-query-types.md
View File

@@ -1,5 +0,0 @@
---
sidebar_position: 4
---
# Типы запросов HTTP

72
docs/api/05-polling.md
View File

@@ -3,3 +3,75 @@ sidebar_position: 5
---
# Polling
**Polling в React** — это техника, при которой клиент (например, веб-приложение) периодически отправляет запросы на сервер для получения обновленных данных. Это полезно, когда нужно поддерживать актуальность данных в реальном времени, но использование более продвинутых технологий, таких как **WebSockets** или **Server-Sent Events (SSE)**, невозможно или нецелесообразно.
## Как реализовать Polling в React:
В React **polling** можно реализовать с помощью встроенных методов, таких как `setInterval`, или с использованием библиотек для управления состоянием и запросами, например, **React Query** или **Apollo Client**.
```jsx
import React, { useState, useEffect } from 'react';
import axios from 'axios';
function PollingExample() {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
useEffect(() => {
const fetchData = async () => {
try {
const response = await axios.get('https://api.example.com/data');
setData(response.data);
} catch (error) {
console.error('Error fetching data:', error);
} finally {
setLoading(false);
}
};
// Первый запрос
fetchData();
// Polling: запрос каждые 5 секунд
const intervalId = setInterval(fetchData, 5000);
// Очистка интервала при размонтировании компонента
return () => clearInterval(intervalId);
}, []);
if (loading) return <p>Loading...</p>;
return (
<div>
<h1>Data from API:</h1>
<pre>{JSON.stringify(data, null, 2)}</pre>
</div>
);
}
export default PollingExample;
```
**Объяснение:**
- `useEffect` используется для выполнения запроса при монтировании компонента.
- `setInterval` запускает запрос каждые 5 секунд.
- `clearInterval` очищает интервал при размонтировании компонента, чтобы избежать утечек памяти.
## Преимущества Polling:
1. **Простота реализации:** Не требует сложной настройки сервера.
2. **Совместимость:** Работает с любым REST или GraphQL API.
3. **Поддержка старых браузеров:** В отличие от WebSockets, polling работает везде.
## Недостатки Polling:
1. **Высокая нагрузка на сервер:** Постоянные запросы могут создавать нагрузку.
2. **Задержки:** Данные обновляются только через заданный интервал.
3. **Неэффективность:** Много запросов могут быть избыточными, если данные не меняются.
## Когда использовать Polling:
- Когда нужно простое решение для обновления данных.
- Когда данные изменяются не очень часто.
- Когда использование WebSockets или SSE невозможно.
## Альтернативы Polling:
1. **WebSockets:** Для реального времени с двусторонней связью.
2. **Server-Sent Events (SSE):** Для односторонней передачи данных от сервера к клиенту.
3. **Long Polling:** Клиент отправляет запрос и ждет, пока сервер не вернет новые данные.

118
docs/api/06-long-polling.md Normal file
View File

@@ -0,0 +1,118 @@
---
sidebar_position: 6
---
# Long Polling
**Long Polling** — это техника, при которой клиент отправляет запрос на сервер и ждет ответа, пока сервер не вернет новые данные или не истечет время ожидания. В отличие от обычного **polling**, где клиент периодически отправляет запросы, **long polling** позволяет серверу "удерживать" запрос до тех пор, пока не появятся новые данные. Это делает **long polling** более эффективным, чем обычный **polling**, особенно для приложений, где данные обновляются нечасто.
Применяется, когда использование **WebSockets** или **SSE** невозможно. В React **long polling** можно легко реализовать с помощью fetch или Axios. Однако для более сложных сценариев лучше использовать **WebSockets** или **SSE**.
## Как работает Long Polling:
1. Клиент отправляет запрос на сервер.
2. Сервер не отвечает сразу, а ждет, пока не появятся новые данные.
3. Как только данные обновляются, сервер отправляет ответ клиенту.
4. Клиент получает ответ и сразу отправляет новый запрос, чтобы продолжить ожидание.
## Преимущества Long Polling:
- **Меньше запросов:** Сервер отвечает только тогда, когда есть новые данные.
- **Более быстрое обновление:** Данные доставляются клиенту сразу после их появления.
- **Простота:** Легче реализовать, чем WebSockets.
## Недостатки Long Polling:
- **Высокая нагрузка на сервер:** Много соединений могут оставаться открытыми.
- **Задержки:** Если данные не обновляются, запросы могут занимать много времени.
- **Сложность масштабирования:** Сервер должен поддерживать множество открытых соединений.
### Пример Long Polling с использованием fetch:
```javascript jsx
import React, { useState, useEffect } from 'react';
function LongPollingExample() {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const fetchData = async () => {
try {
const response = await fetch('https://api.example.com/long-polling');
const result = await response.json();
setData(result);
} catch (error) {
console.error('Error fetching data:', error);
} finally {
setLoading(false);
// После получения данных сразу отправляем новый запрос
fetchData();
}
};
useEffect(() => {
fetchData();
}, []);
if (loading) return <p>Loading...</p>;
return (
<div>
<h1>Data from Long Polling:</h1>
<pre>{JSON.stringify(data, null, 2)}</pre>
</div>
);
}
export default LongPollingExample;
```
**Объяснение:**
1. Запрос отправляется один раз при монтировании компонента.
2. Сервер "удерживает" запрос до тех пор, пока не появятся новые данные.
3. После получения данных клиент сразу отправляет новый запрос.
### Реализация Long Polling с помощью Axios:
Axios позволяет более удобно управлять запросами и обработкой ошибок.
```javascript jsx
import React, { useState, useEffect } from 'react';
import axios from 'axios';
function LongPollingWithAxios() {
const [data, setData] = useState(null);
const [loading, setLoading] = useState(true);
const fetchData = async () => {
try {
const response = await axios.get('https://api.example.com/long-polling');
setData(response.data);
} catch (error) {
console.error('Error fetching data:', error);
} finally {
setLoading(false);
// После получения данных сразу отправляем новый запрос
fetchData();
}
};
useEffect(() => {
fetchData();
}, []);
if (loading) return <p>Loading...</p>;
return (
<div>
<h1>Data from Long Polling:</h1>
<pre>{JSON.stringify(data, null, 2)}</pre>
</div>
);
}
export default LongPollingWithAxios;
```
## Когда использовать Long Polling:
1. Редкие обновления данных: Когда данные обновляются нечасто, но нужно получать их как можно быстрее.
2. Реальное время: Когда WebSockets недоступны или их сложно реализовать.
3. Простота: Когда нужно простое решение для обновления данных.
## Альтернативы Long Polling:
1. WebSockets: Для двусторонней связи в реальном времени.
2. Server-Sent Events (SSE): Для односторонней передачи данных от сервера к клиенту.
3. Обычный Polling: Когда данные обновляются часто, и long polling не нужен.

5
docs/api/06-websocket.md
View File

@@ -1,5 +0,0 @@
---
sidebar_position: 6
---
# Websockets

5
docs/api/07-graphql.md
View File

@@ -1,5 +0,0 @@
---
sidebar_position: 7
---
# GraphQL

132
docs/api/07-server-side-events.md Normal file
View File

@@ -0,0 +1,132 @@
---
sidebar_position: 7
---
# Server Side Events (SSE)
**Server-Sent Events (SSE)** — это технология, которая позволяет серверу отправлять данные клиенту в реальном времени через одно HTTP-соединение. В отличие от WebSockets, SSE поддерживает только одностороннюю связь: сервер отправляет данные клиенту, но клиент не может отправлять данные серверу через SSE. Это делает SSE идеальным для сценариев, где серверу нужно "толкать" данные клиенту, например, для уведомлений, обновлений статуса или потоковой передачи данных.
## Основные особенности SSE:
1. **Односторонняя связь:** Сервер отправляет данные клиенту.
2. **Простота:** Использует стандартный HTTP-протокол.
3. **Автоматическое восстановление соединения:** Если соединение разрывается, клиент автоматически пытается восстановить его.
4. **Поддержка браузеров:** SSE поддерживается большинством современных браузеров.
## Как работает SSE:
1. Клиент создает соединение с сервером с помощью EventSource.
2. Сервер отправляет данные в формате текстового потока.
3. Клиент обрабатывает данные с помощью событий.
## Использование SSE в React:
В React SSE можно использовать с помощью встроенного объекта EventSource. Ниже приведен пример реализации.
```jsx
import React, { useState, useEffect } from 'react';
function SSEDemo() {
const [messages, setMessages] = useState([]);
useEffect(() => {
// Создаем соединение с сервером
const eventSource = new EventSource('https://api.example.com/sse');
// Обработчик события "message"
eventSource.onmessage = (event) => {
const newMessage = event.data;
setMessages((prevMessages) => [...prevMessages, newMessage]);
};
// Обработчик события "error"
eventSource.onerror = (error) => {
console.error('SSE error:', error);
eventSource.close(); // Закрываем соединение при ошибке
};
// Очистка при размонтировании компонента
return () => {
eventSource.close();
};
}, []);
return (
<div>
<h1>Server-Sent Events (SSE) Demo</h1>
<ul>
{messages.map((message, index) => (
<li key={index}>{message}</li>
))}
</ul>
</div>
);
}
export default SSEDemo;
```
**Объяснение:**
1. **EventSource:**
- Создается объект `EventSource`, который подключается к серверу по указанному URL.
- Сервер должен поддерживать SSE и отправлять данные в формате текстового потока.
2. **События:**
- `onmessage:` Обрабатывает данные, полученные от сервера.
- `onerror:` Обрабатывает ошибки соединения.
3. **Очистка:**
- При размонтировании компонента соединение закрывается с помощью `eventSource.close()`.
## Пример серверной реализации (Node.js + Express):
Для работы SSE сервер должен поддерживать отправку данных в формате текстового потока.
```js
const express = require('express');
const app = express();
app.get('/sse', (req, res) => {
// Устанавливаем заголовки для SSE
res.setHeader('Content-Type', 'text/event-stream');
res.setHeader('Cache-Control', 'no-cache');
res.setHeader('Connection', 'keep-alive');
// Отправляем данные клиенту каждые 2 секунды
const intervalId = setInterval(() => {
const data = `Server time: ${new Date().toLocaleTimeString()}`;
res.write(`data: ${JSON.stringify(data)}\n\n`); // Формат SSE
}, 2000);
// Очистка при разрыве соединения
req.on('close', () => {
clearInterval(intervalId);
res.end();
});
});
app.listen(3000, () => {
console.log('Server is running on http://localhost:3000');
});
```
**Объяснение серверной части:**
1. **Заголовки:**
- `Content-Type: text/event-stream:` Указывает, что это поток событий.
- `Cache-Control: no-cache:` Отключает кэширование.
- `Connection: keep-alive:` Поддерживает соединение открытым.
2. **Формат данных:**
- Данные отправляются в формате `data: <message>\n\n`.
3. **Интервал:**
- Сервер отправляет данные клиенту каждые 2 секунды.
## Преимущества SSE:
1. Простота: Легко реализовать как на клиенте, так и на сервере.
2. Автоматическое восстановление: Клиент автоматически переподключается при разрыве соединения.
3. Эффективность: Меньше нагрузки на сервер по сравнению с polling.
## Недостатки SSE:
1. Односторонняя связь: Клиент не может отправлять данные серверу через SSE.
2. Ограниченная поддержка браузеров: Не поддерживается в Internet Explorer.
3. Ограничения протокола: Только текстовые данные.
## Когда использовать SSE:
1. Уведомления: Например, уведомления о новых сообщениях.
2. Обновления статуса: Например, статус заказа или задачи.
3. Потоковая передача данных: Например, ленты новостей или обновления котировок.
## Альтернативы SSE:
1. WebSockets: Для двусторонней связи в реальном времени.
2. Long Polling: Когда SSE недоступен.
3. Polling: Для простых сценариев.

162
docs/api/08-websocket.md Normal file
View File

@@ -0,0 +1,162 @@
---
sidebar_position: 8
---
# Websockets
WebSocket — это протокол связи, который обеспечивает **двустороннюю (full-duplex) связь** между клиентом и сервером в реальном времени. В отличие от HTTP, который работает по модели "запрос-ответ", WebSocket поддерживает постоянное соединение, позволяя серверу и клиенту обмениваться данными в любой момент без необходимости повторного установления соединения.
## Основные особенности WebSocket:
1. **Двусторонняя связь:** Клиент и сервер могут отправлять данные друг другу одновременно.
2. **Реальное время:** Данные передаются мгновенно, как только они доступны.
3. **Эффективность:** Меньше накладных расходов по сравнению с HTTP-запросами.
4. **Поддержка браузеров:** WebSocket поддерживается всеми современными браузерами.
## Как работает WebSocket:
1. Клиент и сервер устанавливают соединение через HTTP-запрос (handshake).
2. После успешного handshake соединение переключается на протокол WebSocket.
3. Клиент и сервер могут отправлять данные друг другу в реальном времени.
4. Соединение остается открытым, пока одна из сторон не закроет его.
## Использование WebSocket в React:
В React WebSocket можно использовать с помощью встроенного объекта `WebSocket`. Ниже приведен пример реализации.
**Пример использования WebSocket в React:**
```jsx
import React, { useState, useEffect } from 'react';
function WebSocketDemo() {
const [messages, setMessages] = useState([]);
const [inputValue, setInputValue] = useState('');
useEffect(() => {
// Создаем WebSocket-соединение
const socket = new WebSocket('wss://api.example.com/socket');
// Обработчик открытия соединения
socket.onopen = () => {
console.log('WebSocket connection established');
};
// Обработчик входящих сообщений
socket.onmessage = (event) => {
const newMessage = event.data;
setMessages((prevMessages) => [...prevMessages, newMessage]);
};
// Обработчик ошибок
socket.onerror = (error) => {
console.error('WebSocket error:', error);
};
// Обработчик закрытия соединения
socket.onclose = () => {
console.log('WebSocket connection closed');
};
// Очистка при размонтировании компонента
return () => {
socket.close();
};
}, []);
// Отправка сообщения на сервер
const sendMessage = () => {
const socket = new WebSocket('wss://api.example.com/socket');
if (socket.readyState === WebSocket.OPEN) {
socket.send(inputValue);
setInputValue('');
} else {
console.error('WebSocket is not open');
}
};
return (
<div>
<h1>WebSocket Demo</h1>
<ul>
{messages.map((message, index) => (
<li key={index}>{message}</li>
))}
</ul>
<input
type="text"
value={inputValue}
onChange={(e) => setInputValue(e.target.value)}
/>
<button onClick={sendMessage}>Send</button>
</div>
);
}
export default WebSocketDemo;
```
**Объяснение:**
1. **Создание WebSocket-соединения:**
- Используется объект `WebSocket`, который подключается к серверу по URL (например, `wss://api.example.com/socket`).
2. **События WebSocket:**
- `onopen`: Срабатывает при успешном установлении соединения.
- `onmessage`: Срабатывает при получении данных от сервера.
- `onerror`: Срабатывает при возникновении ошибки.
- `onclose`: Срабатывает при закрытии соединения.
3. **Отправка данных:**
- Метод `socket.send()` используется для отправки данных на сервер.
4. **Очистка:**
- При размонтировании компонента соединение закрывается с помощью `socket.close()`.
## Пример серверной реализации (Node.js + ws):
Для работы с WebSocket на сервере можно использовать библиотеку ws.
```js
const WebSocket = require('ws');
const server = new WebSocket.Server({ port: 8080 });
server.on('connection', (socket) => {
console.log('New client connected');
// Отправка сообщения клиенту
socket.send('Welcome to the WebSocket server!');
// Обработка входящих сообщений
socket.on('message', (message) => {
console.log(`Received: ${message}`);
// Отправка ответа клиенту
socket.send(`You said: ${message}`);
});
// Обработка закрытия соединения
socket.on('close', () => {
console.log('Client disconnected');
});
});
console.log('WebSocket server is running on ws://localhost:8080');
```
**Объяснение серверной части:**
1. **Создание сервера:**
- Используется библиотека `ws` для создания WebSocket-сервера.
2. **Обработка соединений:**
- Сервер прослушивает входящие соединения и обрабатывает сообщения.
3. **Отправка данных:**
- Сервер отправляет данные клиенту с помощью `socket.send()`.
## Преимущества WebSocket:
1. **Реальное время:** Данные передаются мгновенно.
2. **Двусторонняя связь:** Клиент и сервер могут обмениваться данными одновременно.
3. **Эффективность:** Меньше накладных расходов по сравнению с HTTP.
## Недостатки WebSocket:
1. **Сложность:** Требуется больше усилий для реализации и поддержки.
2. **Ограничения:** Не все прокси и брандмауэры поддерживают WebSocket.
3. **Поддержка браузеров:** Хотя WebSocket поддерживается всеми современными браузерами, могут быть проблемы с устаревшими версиями.
## Когда использовать WebSocket:
1. **Чат-приложения:** Для мгновенного обмена сообщениями.
2. **Онлайн-игры:** Для синхронизации действий игроков.
3. **Финансовые приложения:** Для отображения котировок в реальном времени.
4. **Коллаборативные инструменты:** Например, совместное редактирование документов.
## Альтернативы WebSocket:
1. **Server-Sent Events (SSE):** Для односторонней связи (сервер → клиент).
2. **Long Polling:** Когда WebSocket недоступен.
3. **Polling:** Для простых сценариев.

5
docs/architecture/01-review.md
View File

@@ -1,5 +0,0 @@
---
sidebar_position: 1
---
# Обзор архитектур

0
docs/architecture/02-classic.md → docs/architecture/02-classic-layer-based-arch.md
View File

0
docs/architecture/04-domain.md → docs/architecture/04-ddd-domain-driven-design.md
View File

5
docs/architecture/05-feature-slice-desing.md
View File

@@ -1,5 +0,0 @@
---
sidebar_position: 5
---
# Feature slice design

115
docs/architecture/05-fsd-feature-slice-design.md Normal file
View File

@@ -0,0 +1,115 @@
---
sidebar_position: 5
---
# Feature slice design
**Feature Slice Design (FSD)** — это методология проектирования и организации кода во фронтенд-разработке, которая фокусируется на разделении приложения на независимые, функционально завершённые блоки (срезы), каждый из которых соответствует определённой фиче (функциональности) продукта. Этот подход помогает создавать более структурированные, масштабируемые и поддерживаемые приложения.
## Основные идеи FSD:
1. **Организация по фичам, а не по типам файлов:**
- Вместо традиционного разделения на папки типа `components`, `pages`, `store`, код организуется вокруг функциональных блоков (фич).
- Например, для фичи "Корзина покупок" создаётся отдельная папка, внутри которой находятся все связанные с ней компоненты, стили, логика и тесты.
2. **Изоляция функциональности:**
- Каждая фича (срез) максимально независима от других. Это позволяет разрабатывать, тестировать и изменять её без влияния на остальные части приложения.
3. **Переиспользуемость:**
- Общие части (например, UI-компоненты или утилиты) выносятся в отдельный слой, который может использоваться несколькими фичами.
4. **Масштабируемость:**
- По мере роста приложения новые фичи добавляются как отдельные модули, что упрощает поддержку и развитие проекта.
### Пример структуры проекта с использованием FSD:
```
src/
│
├── features/
│ ├── cart/ # Фича "Корзина"
│ │ ├── components/ # Компоненты, специфичные для корзины
│ │ ├── hooks/ # Хуки для корзины
│ │ ├── store/ # Логика состояния (например, Redux slice)
│ │ └── index.ts # Экспорт фичи
│ │
│ └── auth/ # Фича "Авторизация"
│ ├── components/
│ ├── hooks/
│ ├── store/
│ └── index.ts
│
├── shared/ # Общие компоненты и утилиты
│ ├── ui/ # UI-компоненты (кнопки, инпуты и т.д.)
│ └── lib/ # Утилиты и хелперы
│
└── app/ # Основная логика приложения (роутинг, провайдеры и т.д.)
```
### Понятия
Слои, слайсы и сегменты образуют иерархию, как показано на схеме:
![](images/05-fsd-1.png)
На картинке выше: три столбика, обозначенные слева направо как `"Слои"`, `"Слайсы"` и `"Сегменты"` соответственно.
Столбик **"Слои"** содержит семь делений, расположенных сверху вниз и обозначенных "app", "processes", "pages", "widgets", "features", "entities" и "shared". Деление "processes" зачеркнуто. Деление "entities" соединено со вторым столбиком "Слайсы", показывая, что второй столбик является содержимым "entities".
Столбик **"Слайсы"** содержит три деления, расположенных сверху вниз и обозначенных "user", "post" и "comment". Деление "post" соединено со столбиком "Сегменты" таким же образом, что и содержимое "post".
Столбик **"Сегменты"** содержит три деления, расположенных сверху вниз и обозначенных "ui", "model" и "api".
### Слои
Слои стандартизированы во всех проектах FSD. Вам не обязательно использовать все слои, но их названия важны. На данный момент их семь (сверху вниз):
1. **App** — всё, благодаря чему приложение запускается — роутинг, точки входа, глобальные стили, провайдеры и т. д.
2. **Processes (процессы, устаревший)** — сложные межстраничные сценарии.
3. **Pages (страницы)** — полные страницы или большие части страницы при вложенном роутинге.
4. **Widgets (виджеты)** — большие самодостаточные куски функциональности или интерфейса, обычно реализующие целый пользовательский сценарий.
5. **Features (фичи)** — повторно используемые реализации целых фич продукта, то есть действий, приносящих бизнес-ценность пользователю.
6. **Entities (сущности)** — бизнес-сущности, с которыми работает проект, например user или product.
7. **Shared** — переиспользуемый код, особенно когда он отделён от специфики проекта/бизнеса, хотя это не обязательно.
Слои **App** и **Shared**, в отличие от других слоев, не имеют слайсов и состоят из сегментов напрямую.
Фишка слоев в том, что модули на одном слое могут знать только о модулях со слоев строго ниже, и как следствие, импортировать только с них.
### Слайсы
Дальше идут слайсы, они делят слой по предметной области. Вы можете называть ваши слайсы как угодно, и создавать их сколько угодно. Слайсы помогают не теряться в проекте, потому что группируют тесно связанный по смыслу код.
Слайсы не могут использовать другие слайсы на том же слое, и это обеспечивает сильную связанность кода внутри слайса и слабую сцепленность между слайсами.
### Сегменты
Слайсы, а также слои App и Shared, состоят из сегментов, а сегменты группируют код по его назначению. Имена сегментов не зафиксированы стандартом, но существует несколько общепринятых имен для наиболее распространенных целей:
- `ui` — всё, что связано с отображением: UI-компоненты, форматтеры дат, стили и т.д.
- `api` — взаимодействие с бэкендом: функции запросов, типы данных, мапперы.
- `model` — модель данных: схемы валидации, интерфейсы, хранилища и бизнес-логика.
- `lib` — библиотечный код, который нужен другим модулям этого слайса.
- `config` — файлы конфигурации и фиче-флаги.
Обычно этих сегментов достаточно для большинства слоев, поэтому свои собственные сегменты обычно создают только в Shared или App, но это не жёсткое правило.
### Преимущества
- **Однородность** \
Поскольку структура стандартизирована, проекты становятся более единообразными, что облегчает набор новых участников в команду.
- **Устойчивость к изменениям и рефакторингу** \
Модуль на одном слое не может использовать другие модули на том же слое или слоях выше. \
Это позволяет вам вносить изолированные правки без непредвиденных последствий для остальной части приложения.
- **Контролируемое переиспользование логики** \
В зависимости от уровня вы можете сделать код либо очень переиспользуемым, либо очень локальным.\
Это сохраняет баланс между соблюдением принципа DRY и практичностью.
- **Ориентация на потребности бизнеса и пользователей** \
Приложение разделено на бизнес-домены, и при именовании поощряется использование терминологии бизнеса, чтобы вы могли делать полезную работу в продукте, не вникая полностью во все другие несвязанные части проекта.
## Когда использовать Feature Slice Design
- В крупных проектах с большим количеством функциональных блоков.
- В командах, где разные разработчики работают над разными фичами.
- Когда требуется высокая степень переиспользуемости и модульности.
## Преимущества FSD:
- **Упрощение разработки:** Легче фокусироваться на одной фиче, не отвлекаясь на остальные части приложения.
- **Улучшение поддерживаемости:** Изменения в одной фиче не затрагивают другие.
- **Гибкость:** Фичи можно легко добавлять, удалять или заменять.
- **Тестируемость:** Каждая фича может быть протестирована изолированно.
## Когда использовать FSD:
- В крупных проектах с множеством функциональных блоков.
- Когда требуется высокая степень переиспользуемости и модульности.
- В командах, где разные разработчики работают над разными фичами.
## Альтернативы:
- **Layer-based architecture** (разделение на слои, например, components, pages, store).
- **Domain-driven design (DDD)** (организация кода вокруг доменных областей).

111
docs/architecture/06-micro-frontend.md
View File

@@ -3,3 +3,114 @@ sidebar_position: 6
---
# Micro frontend
Микрофронтенды (Micro Frontends) — это архитектурный подход, который позволяет разделить фронтенд-приложение на независимые, слабо связанные части, каждая из которых может разрабатываться, тестироваться и развертываться отдельно. Этот подход вдохновлен микросервисной архитектурой и применяется для создания масштабируемых и поддерживаемых фронтенд-приложений.
Основные принципы разделения фронтенд-приложения на микрофронтенды:
## 1. Разделение по бизнес-возможностям (Business Capabilities):
- Каждый микрофронтенд должен отвечать за конкретную бизнес-возможность или функциональность (например, корзина покупок, профиль пользователя, каталог товаров).
- Это позволяет командам фокусироваться на своей области ответственности и независимо развивать свои части приложения.
**Пример:**
- Микрофронтенд "Каталог товаров" отвечает за отображение и фильтрацию товаров.
- Микрофронтенд "Корзина" отвечает за управление корзиной покупок.
## 2. Автономность (Autonomy):
- Каждый микрофронтенд должен быть независимым: разрабатываться, тестироваться и развертываться отдельно от других.
- Это позволяет командам работать независимо, не блокируя друг друга.
**Как достичь:**
- Использование отдельных репозиториев для каждого микрофронтенда.
- Независимые CI/CD-пайплайны для сборки и деплоя.
## 3. Изоляция (Isolation):
- Микрофронтенды должны быть изолированы друг от друга, чтобы изменения в одном микрофронтенде не влияли на другие.
- Это достигается за счет четких границ между частями приложения.
**Как достичь:**
- Использование iframe, Web Components или модульных систем (например, Module Federation в Webpack).
- Минимизация общих зависимостей между микрофронтендами.
## 4. Слабая связанность (Loose Coupling):
- Микрофронтенды должны взаимодействовать через четко определенные интерфейсы (API, события, сообщения).
- Это позволяет изменять внутреннюю реализацию одного микрофронтенда, не затрагивая другие.
**Пример:**
Микрофронтенд "Корзина" может подписываться на события от микрофронтенда "Каталог" (например, "товар добавлен в корзину").
## 5.Единый пользовательский интерфейс (Unified User Interface):
- Несмотря на разделение, приложение должно выглядеть и работать как единое целое.
- Это требует согласованности в дизайне, стилях и взаимодействии.
**Как достичь:**
- Использование общей библиотеки компонентов (например, Storybook).
- Согласованные стандарты стилей (например, CSS-in-JS, общие переменные).
## 6. Масштабируемость (Scalability):
- Архитектура должна поддерживать добавление новых микрофронтендов без значительных изменений в существующих частях.
- Это важно для больших команд и проектов, которые развиваются со временем.
**Как достичь:**
- Использование модульной системы (например, Webpack Module Federation).
- Четкие правила интеграции новых микрофронтендов.
## 7. Технологическая независимость (Technology Agnosticism):
- Разные микрофронтенды могут быть написаны на разных технологиях (React, Vue, Angular и т.д.).
- Это позволяет командам выбирать подходящие инструменты для своих задач.
**Пример:**
- Микрофронтенд "Каталог" написан на React.
- Микрофронтенд "Корзина" написан на Vue.
## 8. Совместное использование ресурсов (Shared Resources):
- Общие ресурсы (например, библиотеки, стили, утилиты) должны быть вынесены в отдельные модули или пакеты.
- Это помогает избежать дублирования кода.
**Как достичь:**
- Создание общей библиотеки компонентов.
- Использование монорепозиториев (например, Nx, Lerna) для управления общими зависимостями.
## 9. Маршрутизация (Routing):
- Маршрутизация между микрофронтендами должна быть четко организована.
- Это может быть реализовано как на уровне клиента (например, с помощью React Router), так и на уровне сервера (например, с помощью Nginx).
**Пример:**
- Маршрут /catalog загружает микрофронтенд "Каталог".
- Маршрут /cart загружает микрофронтенд "Корзина".
## 10. Безопасность (Security):
- Каждый микрофронтенд должен быть защищен от несанкционированного доступа.
- Это особенно важно, если микрофронтенды взаимодействуют с разными API или сервисами.
**Как достичь:**
- Использование CORS, JWT-токенов и других механизмов безопасности.
- Изоляция данных между микрофронтендами.
## Пример архитектуры микрофронтендов:
1. **Микрофронтенд "Каталог":**
- Отвечает за отображение товаров и фильтров.
- Написан на React.
- Взаимодействует с API каталога.
2. **Микрофронтенд "Корзина":**
- Отвечает за управление корзиной покупок.
- Написан на Vue.
- Взаимодействует с API корзины.
3. **Микрофронтенд "Профиль":**
- Отвечает за управление профилем пользователя.
- Написан на Angular.
- Взаимодействует с API профиля.
4. **Общая библиотека компонентов:**
- Содержит общие UI-компоненты (кнопки, формы, заголовки).
- Используется всеми микрофронтендами.
## Преимущества микрофронтендов:
1. Независимость команд: Команды могут работать над своими частями приложения, не блокируя друг друга.
2. Гибкость в выборе технологий: Каждая команда может использовать подходящие для её задач технологии.
3. Масштабируемость: Легко добавлять новые функции или микрофронтенды.
4. Упрощение поддержки: Меньшие и более простые части кода легче поддерживать.
## Недостатки микрофронтендов:
1. Сложность интеграции: Требуется четкая организация взаимодействия между микрофронтендами.
2. Дублирование кода: Возможно дублирование общих ресурсов, если они не вынесены в отдельные модули.
3. Производительность: Загрузка нескольких микрофронтендов может увеличить время загрузки приложения.

62
docs/architecture/07-tdd.md
View File

@@ -3,3 +3,65 @@ sidebar_position: 7
---
# Test driven development
TDD (Test-Driven Development) — это методология разработки программного обеспечения, в которой написание тестов предшествует написанию кода. Основная идея TDD заключается в том, что разработчик сначала пишет тест для новой функциональности, а затем реализует код, который делает этот тест успешным. Этот процесс повторяется для каждой новой функции или улучшения.
TDD основан на нескольких ключевых принципах, которые помогают создавать качественный, поддерживаемый и надежный код. Рассмотрим основные принципы TDD:
## 1. Красный — Зеленый — Рефакторинг (Red — Green — Refactor):
Это основной цикл TDD, который состоит из трех этапов:
1. **Красный (Red):**
- Написание теста для новой функциональности, который изначально не проходит (тест "красный", так как функциональность ещё не реализована).
- Это помогает четко определить требования к коду.
2. **Зеленый (Green):**
- Написание минимального количества кода, необходимого для того, чтобы тест прошел (тест становится "зеленым").
- На этом этапе важно не добавлять лишнюю функциональность.
3. **Рефакторинг (Refactor):**
- Улучшение кода без изменения его поведения (например, устранение дублирования, улучшение читаемости).
- Рефакторинг выполняется только после того, как все тесты проходят.
## 2. Тестируемый код:
- Код, написанный с использованием TDD, изначально проектируется так, чтобы его можно было легко тестировать.
- Это часто приводит к более модульной и слабо связанной архитектуре.
## 3. Постепенное развитие (Incremental Development):
- Функциональность добавляется небольшими шагами, каждый из которых сопровождается тестами.
- Это позволяет избежать создания сложных и труднотестируемых систем.
## 4. Тесты как документация:
- Набор тестов служит живой документацией для кода, показывая, как он должен работать.
- Это особенно полезно для новых разработчиков, которые могут быстро понять, что делает код.
## 5. Минимальный рабочий код (Minimal Working Code):
- На этапе "зеленого" теста пишется только тот код, который необходим для прохождения теста.
- Это помогает избежать переусложнения и добавления ненужной функциональности.
## 6. Частые запуски тестов:
- Тесты запускаются после каждого изменения кода, чтобы убедиться, что новая функциональность не сломала существующую.
- Это помогает быстро находить и исправлять ошибки.
## 7. Покрытие кода тестами (Code Coverage):
- TDD стремится к максимальному покрытию кода тестами, чтобы минимизировать вероятность ошибок.
- Однако важно помнить, что 100% покрытие не всегда гарантирует отсутствие багов.
## Преимущества TDD:
1. Высокое качество кода:
- Код, написанный с использованием TDD, обычно более надежен и меньше подвержен ошибкам.
2. Упрощение рефакторинга:
- Наличие тестов позволяет безопасно вносить изменения в код, не боясь сломать существующую функциональность.
3. Четкие требования:
- Тесты помогают четко определить, что именно должен делать код.
4. Раннее обнаружение ошибок:
- Ошибки обнаруживаются на ранних этапах разработки, что снижает стоимость их исправления.
5. Улучшение архитектуры:
- Код становится более модульным и слабо связанным, так как он изначально проектируется для тестирования.
## Недостатки TDD:
1. Дополнительные затраты времени:
- Написание тестов требует времени, что может замедлить начальные этапы разработки.
2. Кривая обучения:
- TDD требует определенного уровня навыков и дисциплины, что может быть сложно для новичков.
3. Не всегда подходит:
- TDD может быть избыточным для небольших проектов или прототипов.

155
docs/architecture/08-dev-principles.md Normal file
View File

@@ -0,0 +1,155 @@
---
sidebar_position: 8
---
# Принципы разработки
Источник: DeepSeek \
Дополнительный источник: [https://habr.com/ru/companies/itelma/articles/546372/](https://habr.com/ru/companies/itelma/articles/546372/)
## YAGNI
_You Aren’t Gonna Need It / Вам это не понадобится_
Принцип YAGNI (англ. You Aren’t Gonna Need It — «Вам это не понадобится») — это концепция из методологии разработки программного обеспечения, которая гласит, что не следует добавлять функциональность в код до тех пор, пока она действительно не потребуется. Этот принцип является частью экстремального программирования (XP) и тесно связан с другими принципами, такими как KISS (Keep It Simple, Stupid) и DRY (Don’t Repeat Yourself).
### Основные идеи YAGNI:
1. **Избегание преждевременной оптимизации:**
- Не стоит тратить время на написание кода, который, возможно, никогда не будет использован.
- Это помогает избежать усложнения системы и снижает вероятность внесения ошибок.
2. **Фокус на текущих требованиях:**
- Разработчики должны сосредоточиться на реализации только тех функций, которые необходимы прямо сейчас.
- Это позволяет быстрее выпускать рабочие версии продукта и получать обратную связь от пользователей.
3. **Упрощение кода:**
- YAGNI способствует написанию более простого и понятного кода, так как в нем отсутствуют лишние элементы.
- Это облегчает поддержку и модификацию кода в будущем.
4. **Экономия времени и ресурсов:**
- Не нужно тратить время на разработку и тестирование функциональности, которая может оказаться ненужной.
- Это позволяет сосредоточиться на действительно важных задачах.
### Преимущества YAGNI:
- Снижение сложности кода.
- Уменьшение времени на разработку.
- Более гибкая реакция на изменения требований.
- Упрощение тестирования и поддержки.
### Когда YAGNI не применим:
- Если есть четкое понимание, что функциональность точно понадобится в ближайшем будущем.
- Если добавление функциональности позже будет значительно дороже или сложнее.
### Дополнительно
Этот принцип прост и очевиден, но ему далеко не все следуют. Если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится позже. \
Этот принцип применим при рефакторинге. Если вы занимаетесь рефакторингом метода, класса или файла, не бойтесь удалять лишние методы. Даже если раньше они были полезны – теперь они не нужны. \
Может наступить день, когда они снова понадобятся – тогда вы сможете воспользоваться git-репозиторием, чтобы воскресить их из мертвых.
## DRY
_Don’t Repeat Yourself / Не повторяйтесь_
Принцип DRY (англ. Don’t Repeat Yourself — «Не повторяйся») — это один из ключевых принципов разработки программного обеспечения, который направлен на минимизацию дублирования кода. Основная идея заключается в том, что каждая часть знания или логики в системе должна иметь единственное, однозначное и авторитетное представление в коде.
### Основные идеи DRY:
1. **Устранение дублирования:**
- Если один и тот же код или логика повторяются в нескольких местах, это увеличивает сложность поддержки и повышает риск ошибок.
- Вместо этого следует выносить повторяющийся код в отдельные функции, модули или классы.
2. **Единая точка изменения:**
- Если логика должна быть изменена, это нужно сделать только в одном месте, а не во всех местах, где она используется.
- Это упрощает поддержку и снижает вероятность ошибок.
3. **Повышение читаемости и поддерживаемости:**
- Код становится более компактным и понятным, так как логика не размазана по всей кодовой базе.
### Преимущества DRY:
1. **Снижение ошибок:**
- Меньше вероятность того, что изменения в логике будут внесены только в одном месте, а в других — забыты.
2. **Упрощение поддержки:**
- Легче вносить изменения, так как логика сосредоточена в одном месте.
3. **Улучшение читаемости:**
- Код становится более структурированным и понятным.
4. **Экономия времени:**
- Не нужно копировать и вставлять код, а также тестировать его в нескольких местах.
### Когда DRY не следует применять слепо:
1. **Избыточная абстракция:**
- Иногда попытка устранить дублирование может привести к созданию сложных и ненужных абстракций, которые усложняют понимание кода.
2. **Микрооптимизации:**
- Не стоит применять DRY для устранения дублирования, если это незначительные фрагменты кода, которые вряд ли будут изменяться.
3. **Разные контексты:**
- Если дублирующийся код используется в разных контекстах и может изменяться независимо, то его объединение может привести к проблемам.
### Связь с другими принципами:
- **KISS (Keep It Simple, Stupid):** DRY помогает упрощать код, устраняя ненужное дублирование.
- **YAGNI (You Aren’t Gonna Need It):** DRY не следует применять для создания абстракций, которые могут понадобиться в будущем, но не нужны сейчас.
### Дополнительно
Эта концепция была впервые сформулирована в книге Энди Ханта и Дэйва Томаса «Программист-прагматик: путь от подмастерья к мастеру».\
Идея вращается вокруг единого источника правды (single source of truth — SSOT). Что это вообще такое? \
Дублирование кода – пустая трата времени и ресурсов. Вам придется поддерживать одну и ту же логику и тестировать код сразу в двух местах, причем если вы измените код в одном месте, его нужно будет изменить и в другом. \
В большинстве случаев дублирование кода происходит из-за незнания системы. Прежде чем что-либо писать, проявите прагматизм: осмотритесь. Возможно, эта функция где-то реализована. Возможно, эта бизнес-логика существует в другом месте. Повторное использование кода – всегда разумное решение.
## KISS
_Keep It Simple, Stupid / Будь проще_
Принцип KISS (англ. Keep It Simple, Stupid — «Делай проще, тупица») — это концепция в разработке программного обеспечения, которая подчеркивает важность простоты и минимализма в проектировании и реализации систем. Основная идея заключается в том, что простые решения чаще всего являются лучшими, так как их легче понимать, поддерживать и модифицировать.
### Основные идеи KISS:
1. **Упрощение кода:**
- Код должен быть настолько простым, насколько это возможно, но не проще.
- Сложные конструкции и избыточные абстракции следует избегать.
2. **Минимизация сложности:**
- Чем проще система, тем меньше вероятность возникновения ошибок и тем легче её поддерживать.
- Простота также облегчает понимание кода новыми разработчиками.
3. **Фокус на решении задачи:**
- Не стоит добавлять функциональность, которая не требуется для решения текущей задачи.
- Это связано с принципом **YAGNI** (You Aren’t Gonna Need It).
4. **Избегание «умного» кода:**
- Код, который выглядит «умным» (например, с использованием сложных языковых конструкций или оптимизаций), часто сложен для понимания и поддержки.
- Лучше писать код, который легко читать и понимать.
### Преимущества KISS:
1. **Упрощение поддержки:**
- Простой код легче понимать и изменять, что снижает затраты на поддержку.
- Снижение вероятности ошибок:
- Чем меньше сложность, тем меньше вероятность допустить ошибку.
2. **Ускорение разработки:**
- Простые решения быстрее реализуются и тестируются.
3. **Улучшение читаемости:**
- Код становится более понятным для других разработчиков, что особенно важно в командной работе.
### Когда KISS не следует применять слепо:
1. **Оптимизация производительности:**
- Иногда для достижения необходимой производительности требуется более сложный код.
- Однако даже в таких случаях следует стремиться к балансу между простотой и эффективностью.
2. **Специфические требования:**
- В некоторых случаях сложные решения могут быть оправданы, если они соответствуют бизнес-требованиям или ограничениям системы.
### Связь с другими принципами:
- **YAGNI (You Aren’t Gonna Need It):** KISS поддерживает идею о том, что не следует добавлять ненужную функциональность.
- **DRY (Don’t Repeat Yourself):** KISS помогает избегать избыточного дублирования, но не за счет усложнения кода.
- **SOLID:** KISS дополняет принципы SOLID, делая акцент на простоте и ясности кода.
### Дополнительно
Этот принцип был разработан ВМС США в 1960 году. Этот принцип гласит, что простые системы будут работать лучше и надежнее.\
Применительно к разработке ПО он значит следующее – не придумывайте к задаче более сложного решения, чем ей требуется.\
Иногда самое разумное решение оказывается и самым простым. Написание производительного, эффективного и простого кода – это прекрасно.
## SOLID
Принципы SOLID — это набор из пяти ключевых принципов объектно-ориентированного программирования и проектирования, которые помогают создавать гибкие, поддерживаемые и масштабируемые программные системы. Аббревиатура SOLID была введена Робертом Мартином (известным также как Uncle Bob) и расшифровывается следующим образом:
### Simple responsibility principle (принцип единой ответственности)
У класса должна быть только одна причина для изменения, то есть у него должна быть только одна ответственность или работа. Этот принцип помогает сделать занятия более целенаправленными, более понятными и менее подверженными ошибкам.
### Open – Closed Principle (Принцип открытости/закрытости)
Программные сущности должны быть открыты для расширения, но закрыты для модификации. Это означает, что вы должны иметь возможность добавлять новые функции в систему, не изменяя существующий код.
Мы можем расширить функциональный компонент и добавить новый компонент пользовательского интерфейса, не затрагивая первый/базовый компонент. Это реализация открытости для расширения, но закрытости для модификации.
### Liskov Substitution principe (принцип замены Лискова)
Объекты суперкласса должны быть заменяемы объектами его подклассов без нарушения корректности программы. Другими словами, подклассы должны иметь возможность заменять свои базовые классы без возникновения ошибок.
### Interface segregation principle (Принцип разделения интерфейсов)
Клиентов не следует заставлять зависеть от интерфейсов, которые они не используют. Вместо этого интерфейсы следует разделить на более мелкие, более целенаправленные интерфейсы, соответствующие потребностям клиента.
### Dependency inversion principle (Инверсия зависимости)
Высокоуровневые модули не должны зависеть от низкоуровневых модулей. Вместо этого, оба должны зависеть от абстракций. Это помогает в разъединении модулей, делая их более пригодными для повторного использования и более простыми для тестирования.
### Преимущества SOLID:
1. **Гибкость:** Код становится проще расширять и модифицировать.
2. **Поддерживаемость:** Упрощается понимание и исправление ошибок.
3. **Тестируемость:** Код, соответствующий SOLID, легче тестировать.
4. **Масштабируемость:** Система становится более устойчивой к изменениям и росту.

BIN
docs/architecture/images/05-fsd-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 59 KiB

2
docs/react/01-intro.md
View File

@@ -3,6 +3,8 @@ sidebar_position: 1
---
# Зачем нужен React
Источник: DeepSeek
Библиотека React — это одна из самых популярных библиотек для создания пользовательских интерфейсов (UI) на JavaScript. Она разработана Facebook (ныне Meta) и активно используется для разработки веб-приложений, мобильных приложений (с помощью React Native) и даже десктопных приложений. Вот основные причины, зачем нужна React, её преимущества и недостатки:
## Зачем нужна React?

2
docs/react/02-v-dom.md
View File

@@ -3,6 +3,8 @@ sidebar_position: 2
---
# Виртуальный DOM
Источник: DeepSeek
Механизм работы **Virtual DOM** и **Reconciliation** — это ключевые особенности React, которые делают его быстрым и эффективным для обновления пользовательских интерфейсов. Давайте разберём, как это работает.
## Virtual DOM (Виртуальный DOM)

1
docs/react/03-lifecycle.md
View File

@@ -3,6 +3,7 @@ sidebar_position: 3
---
# Жизненный цикл компонента
Источник: DeepSeek
Жизненный цикл компонента в React описывает этапы, через которые проходит компонент от момента его создания до удаления из DOM. Эти этапы включают инициализацию, обновление и удаление компонента. React предоставляет методы жизненного цикла, которые позволяют разработчикам управлять поведением компонента на каждом этапе.

1
docs/react/04-props-state.md
View File

@@ -3,6 +3,7 @@ sidebar_position: 4
---
# Состояние и пропсы компонентов
Источник: DeepSeek
В React состояние (state) и пропсы (props) — это два основных способа управления данными в компонентах. Они позволяют
компонентам быть динамичными и реагировать на изменения данных. Однако они используются в разных ситуациях и имеют свои

1
docs/react/05-base-hooks.md
View File

@@ -3,6 +3,7 @@ sidebar_position: 5
---
# Базовые хуки React
Источник: DeepSeek
React предоставляет несколько основных хуков, которые позволяют использовать состояние и другие возможности React в функциональных компонентах. Вот основные хуки:

1
docs/react/06-hocs.md
View File

@@ -3,6 +3,7 @@ sidebar_position: 6
---
# Что такое HOC
Источник: DeepSeek
Higher-Order Components (HOC) — это продвинутая техника в React для повторного использования логики компонентов. HOC — это функция, которая принимает компонент и возвращает новый компонент с дополнительными свойствами или поведением. Это похоже на паттерн декоратора в программировании.

2
docs/react/07-optimization-hooks.md
View File

@@ -3,7 +3,7 @@ sidebar_position: 7
---
# Хуки оптимизации и кэширования
Источник: DeepSeek
## useCallback
`useCallback` — это хук в React, который используется для мемоизации функций. Он помогает оптимизировать производительность компонентов, особенно когда речь идет о передаче функций в дочерние компоненты или их использование в зависимостях других хуков, таких как `useEffect`.

5
docs/react/08-advanced-hooks.md
View File

@@ -1,5 +0,0 @@
---
sidebar_position: 8
---
# Прочие хуки React

67
docs/react/08-users-hooks.md Normal file
View File

@@ -0,0 +1,67 @@
---
sidebar_position: 8
---
# Пользовательские хуки
Источник: DeepSeek
Пользовательские хуки в React — это функции, которые позволяют вам использовать состояние и другие возможности React (например, эффекты, контекст и т.д.) в ваших компонентах, но с возможностью повторного использования логики. Пользовательские хуки помогают избежать дублирования кода и делают его более читаемым и поддерживаемым.
## Основные правила пользовательских хуков:
Имя пользовательского хука должно начинаться с use, чтобы React мог понять, что это хук, и применять к нему соответствующие правила (например, правила хуков).
Пользовательские хуки могут вызывать другие хуки, такие как useState, useEffect, useContext и т.д.
## Преимущества пользовательских хуков:
1. **Повторное использование логики:** Вы можете использовать одну и ту же логику в разных компонентах.
2. **Упрощение компонентов:** Логика выносится из компонента, что делает его более чистым и понятным.
3. **Тестируемость:** Пользовательские хуки можно тестировать отдельно от компонентов.
## Пример: хук для работы с localStorage
```jsx
import { useState } from 'react';
// Пользовательский хук useLocalStorage
function useLocalStorage(key, initialValue) {
const [storedValue, setStoredValue] = useState(() => {
try {
const item = window.localStorage.getItem(key);
return item ? JSON.parse(item) : initialValue;
} catch (error) {
console.log(error);
return initialValue;
}
});
const setValue = (value) => {
try {
const valueToStore = value instanceof Function ? value(storedValue) : value;
setStoredValue(valueToStore);
window.localStorage.setItem(key, JSON.stringify(valueToStore));
} catch (error) {
console.log(error);
}
};
return [storedValue, setValue];
}
// Использование хука в компоненте
function App() {
const [name, setName] = useLocalStorage('name', 'Гость');
return (
<div>
<input
type="text"
value={name}
onChange={(e) => setName(e.target.value)}
placeholder="Введите ваше имя"
/>
<p>Привет, {name}!</p>
</div>
);
}
export default App;
```

104
docs/react/09-render-portal.md
View File

@@ -3,3 +3,107 @@ sidebar_position: 9
---
# Render portal
Источник: DeepSeek
В контексте библиотеки **React**, **Portal (портал)** — это механизм, который позволяет рендерить дочерние элементы
Использование порталов (**Portals**) в React позволяет рендерить элементы вне основного DOM-дерева, сохраняя при этом их
логическую связь с React-компонентами. Это особенно полезно для модальных окон, всплывающих подсказок, уведомлений и
других элементов, которые должны отображаться поверх основного интерфейса.
## Как использовать порталы в React
1. **Создайте целевой DOM-элемент:** \
В вашем HTML-файле создайте элемент, в который будет рендериться содержимое портала. Обычно это делается в
`public/index.html` (если вы используете Create React App).
```html
<div id="root"></div>
<div id="modal-root"></div> <!-- Сюда будет рендериться модальное окно -->
```
2. **Используйте ReactDOM.createPortal:**
В React-компоненте используйте метод `ReactDOM.createPortal`, чтобы рендерить содержимое в целевой DOM-элемент.
3. **Пример использования портала:**
```jsx
import React from 'react';
import ReactDOM from 'react-dom';
// Компонент модального окна
function Modal({children, onClose}) {
return ReactDOM.createPortal(
<div style={{
position: 'fixed',
top: '0',
left: '0',
width: '100%',
height: '100%',
backgroundColor: 'rgba(0, 0, 0, 0.5)',
display: 'flex',
justifyContent: 'center',
alignItems: 'center',
}}>
<div style={{
backgroundColor: 'white',
padding: '20px',
borderRadius: '10px',
boxShadow: '0 2px 10px rgba(0, 0, 0, 0.1)',
}}>
{children}
<button onClick={onClose} style={{marginTop: '10px'}}>Закрыть</button>
</div>
</div>,
document.getElementById('modal-root') // Целевой DOM-элемент
);
}
// Основной компонент
function App() {
const [isModalOpen, setIsModalOpen] = React.useState(false);
return (
<div>
<h1>Пример использования портала</h1>
<button onClick={() => setIsModalOpen(true)}>Открыть модальное окно</button>
{isModalOpen && (
<Modal onClose={() => setIsModalOpen(false)}>
<p>Это модальное окно, отрендеренное через портал!</p>
</Modal>
)}
</div>
);
}
export default App;
```
## Объяснение кода:
1. **Целевой DOM-элемент:**
- В `public/index.html` создан элемент с `id="modal-root"`, в который будет рендериться модальное окно.
2. **Компонент `Modal`:**
- Использует `ReactDOM.createPortal`, чтобы рендерить содержимое модального окна в modal-root.
- Первый аргумент `createPortal` — это JSX, который нужно отрендерить.
- Второй аргумент — это DOM-элемент, в который будет вставлено содержимое.
3. **Компонент `App`:**
- Управляет состоянием модального окна (`isModalOpen`).
- При нажатии на кнопку "Открыть модальное окно" состояние изменяется, и модальное окно отображается через портал.
## Преимущества использования порталов:
1. Логическая связь:
- Элементы, рендерящиеся через портал, остаются частью React-дерева. Это означает, что они могут получать пропсы,
контекст и участвовать в жизненном цикле компонентов.
2. Визуальное отделение:
- Позволяет отображать элементы вне основного DOM-дерева, что полезно для модальных окон, всплывающих подсказок и
т.д.
3. Упрощение стилей:
- Позволяет избежать проблем с z-index и наложением элементов.
## Когда использовать порталы?
- Модальные окна.
- Всплывающие подсказки (tooltips).
- Уведомления.
- Любые элементы, которые должны отображаться поверх основного интерфейса.

31
docs/state-managers/01-intro.md
View File

@@ -3,3 +3,34 @@ sidebar_position: 1
---
# Зачем нужны state менеджеры
Источник: DeepSeek
**State Managers** (менеджеры состояния) в контексте React — это инструменты или библиотеки, которые помогают управлять состоянием приложения. В React состояние (state) — это данные, которые определяют, как компонент должен отображаться и вести себя. Однако, когда приложение становится сложным, управление состоянием только с помощью встроенного `useState` или `useReducer` может стать трудным. Здесь на помощь приходят **state managers**.
## Зачем нужны state managers?
1. **Централизованное управление состоянием:** State managers позволяют хранить состояние в одном месте (store), что упрощает его управление и отладку.
2. **Повторное использование состояния:** Состояние может быть легко доступно в разных компонентах без необходимости передавать его через пропсы (props drilling).
3. **Предсказуемость:** State managers часто используют строгие правила для обновления состояния, что делает поведение приложения более предсказуемым.
4. **Инструменты для отладки:** Многие state managers предоставляют инструменты для отслеживания изменений состояния (например, Redux DevTools).
Популярные state managers для React:
1. **Redux:**
- Самый популярный state manager.
- Использует концепцию _единого хранилища_ (store) и _чистых функций_ (reducers) для обновления состояния.
- Подходит для больших приложений.
2. **Context API:**
- Встроенное решение React для управления состоянием.
- Подходит для небольших приложений или случаев, когда не нужен полноценный state manager.
3. **Zustand:**
- Минималистичный state manager.
- Прост в использовании и не требует большого количества boilerplate-кода.
4. **MobX:**
- Использует observable-объекты для автоматического отслеживания изменений.
- Более прост в использовании, чем Redux.
## Когда использовать state managers?
- Если приложение небольшое, можно обойтись встроенными средствами React (useState, useReducer, Context API).
- Если приложение большое и сложное, с множеством компонентов, которые зависят от общего состояния, лучше использовать специализированные state managers (Redux, MobX, Recoil и т.д.).
## Выбор state manager
Выбор зависит от сложности приложения, предпочтений команды и необходимости в дополнительных функциях (например, middleware в Redux). Для небольших проектов часто достаточно Context API или Zustand, а для крупных — Redux или Recoil.

148
docs/state-managers/02-redux.md
View File

@@ -3,3 +3,151 @@ sidebar_position: 2
---
# Экосистема Redux
Redux — это популярный менеджер состояний (state management library) для JavaScript-приложений, включая React. Он предоставляет централизованное хранилище (store) для управления состоянием всего приложения, что делает его особенно полезным для больших и сложных приложений.
## Основные концепции Redux:
1. **Store (хранилище):**
- Единый источник истины (_single source of truth_) для состояния всего приложения.
- Хранит всё состояние приложения в виде одного большого объекта.
- Создаётся с помощью функции `createStore` (в классическом Redux) или `configureStore` (в Redux Toolkit).
2. **State (состояние):**
- Это данные, которые хранятся в **store**.
- State доступен только для чтения. Чтобы изменить **state**, нужно отправить **action**.
3. **Actions (действия):**
- Это объекты, которые описывают, что должно произойти.
- Действия должны иметь поле `type`, которое указывает на тип действия, и могут содержать дополнительные данные (**payload**).
```js
const increment = () => ({
type: 'INCREMENT',
});
const addTodo = (text) => ({
type: 'ADD_TODO',
payload: text,
});
```
4. **Reducers (редьюсеры):**
- Это чистые функции, которые определяют, как состояние (**state**) изменяется в ответ на действия (**actions**).
- Редьюсер принимает текущее состояние и действие, а затем возвращает новое состояние.
```js
const initialState = { count: 0 };
function counterReducer(state = initialState, action) {
switch (action.type) {
case 'INCREMENT':
return { ...state, count: state.count + 1 };
case 'DECREMENT':
return { ...state, count: state.count - 1 };
default:
return state;
}
}
```
5. **Dispatch (диспетчеризация):**
- Это метод **store**, который используется для отправки действий (**actions**) в редьюсер.
```js
store.dispatch({ type: 'INCREMENT' });
```
6. **Subscribe (подписка):**
- Это метод **store**, который позволяет подписаться на изменения состояния.
```js
store.subscribe(() => {
console.log('State changed:', store.getState());
});
```
## Как Redux работает с React?
Для интеграции Redux с React используется библиотека react-redux, которая предоставляет два основных инструмента:
1. Provider:
- Компонент, который делает store доступным для всех компонентов приложения.
```jsx
import { Provider } from 'react-redux';
import store from './store';
function App() {
return (
<Provider store={store}>
<MyComponent />
</Provider>
);
}
```
2. Hooks:
- useSelector: Позволяет компоненту получать данные из store.
- useDispatch: Позволяет компоненту отправлять действия (actions).
```jsx
import { useSelector, useDispatch } from 'react-redux';
function Counter() {
const count = useSelector((state) => state.count);
const dispatch = useDispatch();
return (
<div>
<p>Count: {count}</p>
<button onClick={() => dispatch({ type: 'INCREMENT' })}>Increment</button>
</div>
);
}
```
## Преимущества Redux:
1. Централизованное состояние:
- Всё состояние приложения хранится в одном месте, что упрощает управление и отладку.
2. Предсказуемость:
- Состояние изменяется только через действия и редьюсеры, что делает поведение приложения предсказуемым.
3. Инструменты разработчика:
- Redux DevTools позволяют отслеживать изменения состояния, отменять действия и многое другое.
4. Масштабируемость:
- Redux хорошо подходит для больших приложений с множеством компонентов и сложной логикой состояния.
5. Сообщество и экосистема:
- Redux имеет огромное сообщество и множество дополнительных библиотек (например, Redux Thunk, Redux Saga).
## Недостатки Redux:
1. Boilerplate:
- Redux требует написания большого количества кода (actions, reducers, store), что может быть избыточным для небольших приложений.
2. Сложность:
- Для новичков Redux может показаться сложным из-за множества концепций и шагов.
3. Производительность:
- Неправильное использование Redux может привести к лишним ререндерам компонентов.
## Redux Toolkit (RTK):
Чтобы упростить работу с Redux, команда разработчиков создала **Redux Toolkit** — официальный набор инструментов для Redux. Он включает:
- **configureStore:** Упрощает создание **store**.
- **createSlice:** Позволяет объединить **actions** и **reducers** в одном месте.
- **createAsyncThunk:** Упрощает работу с асинхронными действиями.
- Встроенную поддержку Redux **DevTools** и **middleware** (например, Thunk).
Пример с Redux Toolkit:
```js
import { createSlice, configureStore } from '@reduxjs/toolkit';
const counterSlice = createSlice({
name: 'counter',
initialState: { value: 0 },
reducers: {
increment: (state) => {
state.value += 1;
},
decrement: (state) => {
state.value -= 1;
},
},
});
const store = configureStore({
reducer: counterSlice.reducer,
});
export const { increment, decrement } = counterSlice.actions;
export default store;
```
## Когда использовать Redux?
- В больших приложениях с множеством компонентов, которые зависят от общего состояния.
- Когда требуется централизованное управление состоянием.
- Когда нужно отслеживать и отлаживать изменения состояния (например, с помощью Redux DevTools).
Для небольших приложений **Redux** может быть избыточным, и в таких случаях лучше использовать **Context API** или другие более простые решения.

53
docs/state-managers/03-rtk-query.md
View File

@@ -3,3 +3,56 @@ sidebar_position: 3
---
# RTK-query
**RTK Query** — это мощная библиотека для управления данными и выполнения запросов к API, встроенная в **Redux Toolkit (RTK)**. Она предназначена для упрощения работы с асинхронными запросами, кэшированием данных и управлением состоянием, связанным с API, в React-приложениях. RTK Query автоматически генерирует редьюсеры, действия и селекторы, что значительно сокращает количество boilerplate-кода.
## Основные возможности RTK Query:
1. **Автоматическое кэширование:**
- RTK Query автоматически кэширует данные, полученные от API, и управляет их актуальностью.
- Повторные запросы к одним и тем же данным не выполняются, если они уже есть в кэше.
2. **Автоматическая генерация хуков:**
- RTK Query генерирует React-хуки (например, `useGetPostsQuery`) для выполнения запросов и управления состоянием загрузки, ошибок и данных.
3. **Интеграция с Redux:**
- RTK Query использует Redux под капотом, что позволяет легко интегрировать её с существующим Redux-стором.
4. **Поддержка мутаций:**
- Помимо запросов на получение данных (queries), RTK Query поддерживает мутации (mutations) для отправки данных на сервер (например, POST, PUT, DELETE).
5. **Оптимизация запросов:**
- RTK Query автоматически управляет подписками на данные, что предотвращает лишние запросы и ререндеры.
6. **Инструменты разработчика:**
- RTK Query интегрируется с Redux DevTools, что позволяет отслеживать состояние запросов и кэша.
Основные хуки RTK Query:
1. useQuery:
- Используется для выполнения **GET**-запросов.
- Возвращает объект с данными, состоянием загрузки (`isLoading`), ошибкой (~~error~~) и другими полезными полями.
- Пример: `useGetPostsQuery()`.
2. useMutation:
- Используется для выполнения **POST**, **PUT**, **DELETE** и других запросов, изменяющих данные на сервере.
- Возвращает функцию для выполнения мутации и объект с состоянием (`isLoading`, `isError` и т.д.).
- Пример: `useAddPostMutation()`.
3. useLazyQuery:
- Используется для выполнения запросов по требованию (например, при нажатии кнопки).
- Пример: `const [fetchPost, { data }] = useLazyGetPostByIdQuery()`.
## Преимущества RTK Query:
1. Минимум boilerplate-кода:
- RTK Query автоматически генерирует редьюсеры, действия и хуки.
2. Кэширование:
- Данные автоматически кэшируются, что предотвращает лишние запросы.
3. Интеграция с Redux:
- RTK Query легко интегрируется с существующим Redux-стором.
4. Оптимизация:
- Автоматическое управление подписками и ререндерами.
5. Поддержка TypeScript:
- RTK Query полностью поддерживает TypeScript, что делает её удобной для типизированных проектов.
## Недостатки RTK Query:
1. Ограниченная гибкость:
- RTK Query ориентирована на REST API и GraphQL. Для более сложных сценариев может потребоваться ручная настройка.
2. Зависимость от Redux:
- Если в проекте не используется Redux, RTK Query может быть избыточной.
## Когда использовать RTK Query?
- Если в приложении много запросов к API и нужно управлять кэшированием.
- Если уже используется Redux Toolkit и нужно упростить работу с API.
- Для приложений, где требуется минимум boilerplate-кода.

58
docs/state-managers/04-zustand.md
View File

@@ -3,3 +3,61 @@ sidebar_position: 4
---
# Zustand
Zustand — это минималистичная и современная библиотека для управления состоянием в React-приложениях. Она предоставляет
простой и интуитивно понятный API для создания и использования хранилищ (stores), что делает её отличной альтернативой
более сложным решениям, таким как Redux или MobX. Zustand легковесен, не требует большого количества boilerplate-кода и
легко интегрируется с React.
## Основные особенности Zustand:
1. Простота:
- Zustand имеет минимальный API, что делает его очень простым в использовании.
- Для начала работы достаточно создать store с помощью функции create.
2. Минимум boilerplate:
- В отличие от Redux, Zustand не требует настройки редьюсеров, действий или middleware.
3. Реактивность:
- Zustand автоматически отслеживает изменения состояния и обновляет компоненты, которые используют store.
4. Гибкость:
- Zustand позволяет хранить как простые, так и сложные состояния, включая асинхронные операции.
5. Интеграция с React:
- Zustand предоставляет хуки для удобного использования store в функциональных компонентах.
6. Производительность:
- Zustand оптимизирован для минимизации лишних ререндеров.
## Преимущества Zustand:
1. Минимализм:
- Zustand предоставляет только необходимый функционал, без лишних сложностей.
2. Простота интеграции:
- Не требуется настройка провайдеров или обёрток, как в Redux.
3. Производительность:
- Zustand оптимизирован для минимизации ререндеров.
4. Гибкость:
- Подходит как для простых, так и для сложных сценариев управления состоянием.
5. TypeScript-поддержка:
- Zustand полностью поддерживает TypeScript, что делает его удобным для типизированных проектов.
## Недостатки Zustand:
1. Ограничение в инструменте для отладки:
- В отличие от Redux, Zustand не имеет таких мощных инструментов, как Redux DevTools, но при этом практически
полностью совместим и может использовать его для отладки.
2. Меньше сообщества:
- Zustand менее популярен, чем Redux, поэтому может быть меньше ресурсов и примеров.
## Когда использовать Zustand?
- Для небольших и средних приложений, где не требуется сложная логика управления состоянием.
- Когда нужно быстро начать работу с минимальной настройкой.
- Если вы хотите избежать boilerplate-кода, характерного для Redux.
## Сравнение Zustand и Redux:
| Характеристика | Zustand | Redux |
|---------------------|------------------------------------------|--------------------------------------------|
| Сложность | Простой и минималистичный | Более сложный, требует boilerplate |
| Настройка | Минимальная | Требует настройки store, middleware |
| Производительность | Оптимизирован для минимизации ререндеров | Может требовать дополнительной оптимизации |
| Инструменты отладки | Ограниченные | Redux DevTools |
| Сообщество | Меньше | Огромное сообщество |

39
docs/state-managers/05-apollo-graphql.md
View File

@@ -3,3 +3,42 @@ sidebar_position: 5
---
# Apollo graphql
**Apollo Client** — это мощная библиотека для работы с GraphQL в React-приложениях. Она предоставляет инструменты для выполнения запросов, управления состоянием, кэширования данных и интеграции с UI. Apollo Client упрощает взаимодействие с GraphQL API, делая процесс разработки более эффективным и удобным.
## Основные возможности Apollo Client:
1. **Выполнение GraphQL-запросов:**
- Apollo Client позволяет легко выполнять запросы (**queries**), мутации (**mutations**) и подписки (**subscriptions**).
2. **Кэширование:**
- Встроенный кэш нормализует данные и автоматически обновляет UI при изменении данных.
3. **Интеграция с React:**
- Apollo Client предоставляет хуки (например, `useQuery`, `useMutation`) для удобной работы с GraphQL в функциональных компонентах.
4. **Поддержка TypeScript:**
- Apollo Client полностью поддерживает TypeScript, что делает его удобным для типизированных проектов.
5. **Инструменты разработчика:**
- Apollo DevTools позволяют отслеживать запросы, кэш и производительность.
6. **Реактивность:**
- Apollo Client автоматически обновляет компоненты при изменении данных.
## Преимущества Apollo Client:
1. **Удобство:**
- Apollo Client предоставляет простой и интуитивно понятный API для работы с GraphQL.
2. **Кэширование:**
- Встроенный кэш автоматически обновляет UI при изменении данных.
3. **Интеграция с React:**
- Хуки (useQuery, useMutation, useSubscription) делают работу с GraphQL в React очень удобной.
4. **Поддержка TypeScript:**
- Apollo Client полностью поддерживает TypeScript.
5. **Инструменты разработчика:**
- Apollo DevTools позволяют отслеживать запросы, кэш и производительность.
## Недостатки Apollo Client:
1. **Размер бандла:**
- Apollo Client добавляет дополнительный вес в бандл приложения.
2. **Сложность для простых сценариев:**
- Для небольших проектов Apollo Client может быть избыточным.
## Когда использовать Apollo Client?
- Если ваше приложение использует GraphQL API.
- Если требуется кэширование данных и автоматическое обновление UI.
- Для сложных приложений с множеством запросов и мутаций.

40
docs/state-managers/06-tenstack-react-query.md
View File

@@ -3,3 +3,43 @@ sidebar_position: 6
---
# React-query
**TanStack Query** (ранее известная как **React Query**) — это мощная библиотека для управления состоянием данных в React-приложениях. Она фокусируется на работе с асинхронными данными, такими как запросы к API, и предоставляет инструменты для кэширования, синхронизации, фонового обновления и управления состоянием загрузки и ошибок. TanStack Query значительно упрощает работу с данными, делая код более чистым и эффективным.
## Основные возможности TanStack Query:
1. **Кэширование данных:**
- Автоматически кэширует данные и управляет их актуальностью.
- Повторные запросы к одним и тем же данным не выполняются, если они уже есть в кэше.
2. **Фоновое обновление:**
- Автоматически обновляет данные в фоновом режиме, чтобы поддерживать их актуальность.
3. **Интеграция с React:**
- Предоставляет хуки (например, `useQuery`, `useMutation`) для удобной работы с данными в функциональных компонентах.
4. **Оптимизация запросов:**
- Управляет подписками на данные, предотвращая лишние запросы и ререндеры.
5. **Поддержка TypeScript:**
- TanStack Query полностью поддерживает TypeScript, что делает её удобной для типизированных проектов.
6. **Инструменты разработчика:**
- Встроенные DevTools позволяют отслеживать состояние запросов и кэша.
## Преимущества TanStack Query:
1. **Минимум boilerplate:**
- TanStack Query автоматически управляет кэшированием, обновлением и ошибками.
2. **Производительность:**
- Оптимизирует запросы и предотвращает лишние ререндеры.
3. **Гибкость:**
- Подходит для работы с REST API, GraphQL и другими источниками данных.
4. **Интеграция с React:**
- Предоставляет удобные хуки для работы с данными.
5. **Поддержка TypeScript:**
- Полностью поддерживает TypeScript.
## Недостатки TanStack Query:
1. **Ориентация на данные:**
- TanStack Query фокусируется на асинхронных данных и не подходит для управления состоянием приложения в целом.
2. **Кривая обучения:**
- Некоторые концепции (например, инвалидация кэша) могут быть сложными для новичков.
## Когда использовать TanStack Query?
- Если ваше приложение активно взаимодействует с API.
- Если требуется кэширование данных и автоматическое обновление UI.
- Для приложений с большим количеством асинхронных запросов.

51
docs/state-managers/07-mobx.md
View File

@@ -3,3 +3,54 @@ sidebar_position: 7
---
# Mobx
**MobX** — это библиотека для управления состоянием в JavaScript-приложениях, включая React. Она использует концепцию **реактивного программирования**, чтобы автоматически отслеживать изменения состояния и обновлять компоненты, которые зависят от этого состояния. MobX известен своей простотой, минимальным количеством boilerplate-кода и высокой производительностью.
## Основные концепции MobX:
1. **Observable State (наблюдаемое состояние):**
- Состояние в MobX помечается как observable, что позволяет библиотеке автоматически отслеживать его изменения.
2. **Actions (действия):**
- Действия — это функции, которые изменяют состояние. Они помечаются как action.
3. **Computed Values (вычисляемые значения):**
- Это значения, которые автоматически вычисляются на основе observable-состояния. Они помечаются как computed.
4. **Reactions (реакции):**
- Реакции — это функции, которые автоматически выполняются при изменении observable-состояния. Например, обновление UI в React-компонентах.
5. **Автоматическая реактивность:**
- MobX автоматически отслеживает зависимости между observable-состоянием и компонентами, что делает код более декларативным.
## Преимущества MobX:
1. **Простота:**
- Минимальный boilerplate-код и интуитивно понятный API.
2. **Реактивность:**
- Автоматическое отслеживание изменений и обновление компонентов.
3. **Производительность:**
- MobX оптимизирует обновления, минимизируя лишние ререндеры.
4. **Гибкость:**
- Подходит как для простых, так и для сложных сценариев управления состоянием.
5. **Поддержка TypeScript:**
- MobX полностью поддерживает TypeScript.
## Как использовать MobX в React?
1. **Установка**
- Установите MobX и mobx-react-lite (или mobx-react для классовых компонентов)
2. **Создание store**
- Создайте store с использованием MobX
3. **Подключение store к React**
- Используйте observer из mobx-react-lite, чтобы сделать компонент реактивным:
4. **Использование нескольких stores**
- Если у вас несколько stores, можно использовать React Context для их передачи
MobX легко работает с асинхронными операциями. Например, можно добавить загрузку данных.
## Недостатки MobX:
1. **Меньше структурированности:**
- В отличие от Redux, MobX не навязывает строгую структуру, что может привести к неорганизованному коду.
2. **Меньше инструментов для отладки:**
- Хотя MobX имеет DevTools, они менее мощные, чем Redux DevTools.
3. **Кривая обучения:**
- Некоторые концепции (например, реакции) могут быть сложными для новичков.
## Когда использовать MobX?
- Для небольших и средних приложений, где требуется простое и эффективное управление состоянием.
- Если вы хотите избежать boilerplate-кода, характерного для Redux.
- Для приложений с большим количеством реактивных данных.