fix: typo, conjunctions, and wording (#804)

Author: Dlazder

i18n/ru/docusaurus-plugin-content-docs/current/guides/examples/auth.md

@@ -98,7 +98,7 @@ export function RegisterPage() {
 
 #### В `shared/api`
 
-Этот подход хорошо сочетается с тем, чтоб размещать в `shared/api` все функции запросов, и группировать их по эндпоинту, например. Структура файлов в таком случае может выглядеть так:
+Этот подход хорошо сочетается с тем, чтобы размещать в `shared/api` все функции запросов, и группировать их по эндпоинту, например. Структура файлов в таком случае может выглядеть так:
 
 - 📂 shared
     - 📂 api
@@ -163,7 +163,7 @@ export function login({ email, password }: { email: string, password: string })
 
 ### В Shared
 
-Этот подход хорошо работает, когда API-клиент определен в `shared/api`, поскольку токен свободно доступен ему для других функций-запросов, которые требуют авторизацию. Вы можете сделать так, чтоб клиент имел свой стейт, либо с помощью реактивного хранилища, либо просто с помощью переменной на уровне модуля. Затем вы можете обновлять этот стейт в ваших функциях `login()`/`logout()`.
+Этот подход хорошо работает, когда API-клиент определен в `shared/api`, поскольку токен свободно доступен ему для других функций-запросов, которые требуют авторизацию. Вы можете сделать так, чтобы клиент имел свой стейт, либо с помощью реактивного хранилища, либо просто с помощью переменной на уровне модуля. Затем вы можете обновлять этот стейт в ваших функциях `login()`/`logout()`.
 
 Автоматическое обновление токена может быть реализовано как middleware в API-клиенте — то, что выполняется каждый раз, когда вы делаете какой-либо запрос. Например, можно сделать так:
 
@@ -181,13 +181,13 @@ export function login({ email, password }: { email: string, password: string })
 
 :::note
 
-**Текущий пользователь** также иногда называется "viewer" или "me". Это делается для того, чтоб различать одного авторизованного пользователя с разрешениями и приватной информацией и всех остальных пользователей с публичной информацией.
+**Текущий пользователь** также иногда называется "viewer" или "me". Это делается для того, чтобы различать одного авторизованного пользователя с разрешениями и приватной информацией и всех остальных пользователей с публичной информацией.
 
 :::
 
-Чтоб хранить токен в сущности User, создайте реактивное хранилище в сегменте `model`. Это хранилище может содержать одновременно и токен, и объект с информацией о пользователе.
+Чтобы хранить токен в сущности User, создайте реактивное хранилище в сегменте `model`. Это хранилище может содержать одновременно и токен, и объект с информацией о пользователе.
 
-Поскольку API-клиент обычно размещается в `shared/api` или распределяется между сущностями, главной проблемой этого подхода является обеспечение доступа к токену для других запросов, не нарушая при этом [правило импортов для слоёв][import-rule-on-layers]:
+Поскольку API-клиент обычно размещается в `shared/api` или распределяется между сущностями, главной проблемой этого подхода является обеспечение доступа к токену для других запросов, без нарушения [правил импортов для слоёв][import-rule-on-layers]:
 
 > Модуль (файл) в слайсе может импортировать другие слайсы только в том случае, если они расположены на слоях строго ниже.
 
@@ -196,19 +196,19 @@ export function login({ email, password }: { email: string, password: string })
 1. **Передавать токен вручную каждый раз, когда делаете запрос**  
     Это самое простое решение, но оно быстро становится неудобным, и если у вас нет строгой типизации, об этом легко забыть. Это решение также несовместимо с паттерном middleware для API-клиента в Shared.
 1. **Открыть доступ к токену для всего приложения через контекст или глобальное хранилище вроде `localStorage`**  
-    Ключ, по которому можно будет получить токен, будет храниться в `shared/api`, чтоб API-клиент мог его использовать. Реактивное хранилище токена будет экспортировано из сущности User, а провайдер контекста (если требуется) будет настроен на слое App. Это дает больше свободы для дизайна API-клиента, но такой подход создаёт неявную зависимость
+    Ключ, по которому можно будет получить токен, будет храниться в `shared/api`, чтобы API-клиент мог его использовать. Реактивное хранилище токена будет экспортировано из сущности User, а провайдер контекста (если требуется) будет настроен на слое App. Это дает больше свободы для дизайна API-клиента, но такой подход создаёт неявную зависимость
 1. **Вставлять токен в API-клиент каждый раз, когда токен меняется**  
     Если ваше хранилище реактивное, то можно подписаться на изменения и обновлять токен в API-клиенте каждый раз, когда хранилище в сущности User меняется. Это похоже на прошлое решение тем, что они оба создают неявную зависимость, но это решение более императивное ("push"), тогда как предыдущее — более декларативное ("pull").
 
-Как только вы решите проблему доступности токена, хранящегося в модели сущности User, вы сможете описать дополнительную бизнес-логику, связанную с управлением токенами. Например, сегмент `model` может содержать логику, которая делает токен недействительным через определенный период времени или обновляет токен по истечении срока его действия. Чтобы совершать запросы на бэкенд для выполнения этих задач, используйте сегмент `api` сущности User или `shared/api`.
+Решив проблему доступности токена, хранящегося в модели сущности User, вы сможете описать дополнительную бизнес-логику, связанную с управлением токенами. Например, сегмент `model` может содержать логику, которая делает токен недействительным через определенный период времени или обновляет токен по истечении срока его действия. Чтобы совершать запросы на бэкенд для выполнения этих задач, используйте сегмент `api` сущности User или `shared/api`.
 
 ### В Pages/Widgets (не рекомендуется)
 
 Не рекомендуется хранить состояние, актуальное для всего приложения, как например токен доступа, в страницах или виджетах. Не стоит размещать хранилище токенов в сегменте `model` на странице логина. Вместо этого выберите одно из первых двух решений: Shared или Entities.
 
 ## Логаут и аннулирование токена
 
-Обычно в приложениях не делают целую отдельную страницу для логаута, но функционал логаута, тем не менее, очень важна. В этот функционал входит авторизованный запрос на бэкенд и обновление хранилища токенов.
+Обычно в приложениях не делают целую отдельную страницу для логаута, но функционал логаута, тем не менее, очень важен. В этот функционал входит авторизованный запрос на бэкенд и обновление хранилища токенов.
 
 Если вы храните все ваши запросы в `shared/api`, оставьте там функцию для запроса на логаут, рядом с функцией для логина. Если нет, разместите функцию-запрос на логаут рядом с кнопкой, которая её вызывает. Например, если у вас есть виджет хэдера, который есть на каждой странице и содержит ссылку для логаута, поместите этот запрос в сегмент `api` этого виджета.