Merge pull request #408 from mnenie/fix/extras-composition_api_faq

fix: translation errors in /guide/extras/composition-api-faq

src/guide/extras/composition-api-faq.md

@@ -14,7 +14,7 @@ outline: deep
 
 Composition API - это набор API, который позволяет нам создавать компоненты Vue, используя импортированные функции вместо объявления опций. Это обобщающий термин, который охватывает следующие API:
 
-- [Reactivity API](/api/reactivity-core), например `ref()` и `reactive()`, что позволяет нам напрямую создавать реактивное состояние, вычисляемое состояние, и watchers.
+- [Reactivity API](/api/reactivity-core), например `ref()` и `reactive()`, что позволяет нам напрямую создавать реактивное состояние, вычисляемое состояние, и наблюдатели.
 
 - [Хуки жизненного цикла](/api/composition-api-lifecycle), например `onMounted()` и `onUnmounted()`, которые позволяют нам программно подключаться к жизненному циклу компонента.
 
@@ -47,7 +47,7 @@ onMounted(() => {
 
 Несмотря на стиль API, основанный на композиции функций, **Composition API НЕ ЯВЛЯЕТСЯ функциональным программированием**. Composition API основан на изменчивой, детализированной парадигме реактивности Vue, тогда как функциональное программирование делает упор на неизменность
 
-Если вам интересно узнать, как использовать Vue с Composition API, вы можете установить для всего сайта предпочитаемое API в Composition API используя переключатель расположенный в верхней части боковой панели сайта с левой стороны, а затем пройти руководство с самого начала.
+Если вам интересно узнать, как использовать Vue с Composition API, вы можете установить для всего сайта предпочитаемое API в Composition API, используя переключатель расположенный в верхней части боковой панели сайта с левой стороны, а затем пройти руководство с самого начала.
 
 ## Почему Composition API? {#why-composition-api}
 
@@ -59,7 +59,7 @@ onMounted(() => {
 
 ### Более гибкая организация кода {#more-flexible-code-organization}
 
-Многим пользователям нравится, что с помощью Options API: мы по умолчанию пишем упорядоченный код: все находится на своем месте в зависимости от того, к какой опции оно относится. Однако, Options API накладывает серьезные ограничения, когда логика одного компонента перерастает определенный порог сложности. Особенно ярко это ограничение проявляется в компонентах, где необходимо решать несколько **логических задач**, что мы воочию можем наблюдать во многих рабочих приложениях Vue 2.
+Многим пользователям нравится, что мы по умолчанию пишем упорядоченный код с использованием Options API: все находится на своем месте в зависимости от того, к какой опции оно относится. Однако, Options API накладывает серьезные ограничения, когда логика одного компонента перерастает определенный порог сложности. Особенно ярко это ограничение проявляется в компонентах, где необходимо решать несколько **логических задач**, что мы наглядно можем наблюдать во многих рабочих приложениях Vue 2.
 
 Возьмем для примера компонент проводника папок из графического интерфейса Vue CLI этот компонент отвечает за следующие логические задачи:
 
@@ -86,13 +86,13 @@ onMounted(() => {
 
 В последние годы все больше и больше разработчиков интерфейсов переходят на [TypeScript](https://www.typescriptlang.org/) поскольку это помогает нам писать более надежный код, вносить изменения с большей уверенностью и обеспечивает отличный опыт разработки с поддержкой IDE. Однако Options API, изначально задуманный в 2013 году, был разработан без учета вывода типов. Нам пришлось реализовать некоторые [абсурдно сложные гимнастические упражнения с типами](https://github.com/vuejs/core/blob/44b95276f5c086e1d88fa3c686a5f39eb5bb7821/packages/runtime-core/src/componentPublicInstance.ts#L132-L165), чтобы вывод типов работал с Options API. Даже при всех этих усилиях вывод типов для Options API может по-прежнему не работать для mixins и dependency injection.
 
-Это привело к тому, что многие разработчики, которые хотели использовать Vue с TS склонялись к Class API основанному на `vue-class-component`. Однако API на основе классов в значительной степени зависит от декораторов ES, языковой функции, которая была предложена только на этапе 2, когда Vue 3 разрабатывался в 2019 году. Мы посчитали слишком рискованным основывать официальный API на нестабильном предложении. С тех пор предложение декораторов претерпело еще одну полную переработку, и наконец, достигло 3 этапа в 2022 году. Кроме того, API на основе классов страдает от повторного использования логики и организационных ограничений, подобных Options API.
+Это привело к тому, что многие разработчики, которые хотели использовать Vue с TS, склонялись к Class API основанному на `vue-class-component`. Однако API на основе классов в значительной степени зависит от декораторов ES, языковой функции, которая была предложена только на этапе 2, когда Vue 3 разрабатывался в 2019 году. Мы посчитали слишком рискованным основывать официальный API на нестабильном предложении. С тех пор предложение декораторов претерпело еще одну полную переработку, и наконец, достигло 3 этапа в 2022 году. Кроме того, API на основе классов страдает от повторного использования логики и организационных ограничений, подобных Options API.
 
 Для сравнения, Composition API использует в основном простые переменные и функции, которые, естественно, дружественны к типам. Код, написанный в Composition API может использовать полный вывод типов с небольшой потребностью в ручных подсказках. Большую часть времени, код Composition API будет выглядеть практически одинаково в TypeScript и простом JavaScript. Это также позволяет обычным пользователям JavaScript извлекать выгоду из частичного вывода типов.
 
 ### Меньший размер production сборки и меньше накладных расходов {#smaller-production-bundle-and-less-overhead}
 
-Код, написанный в Composition API и `<script setup>` также более эффективен и удобен для минификации, чем аналогичный в Options API. Это связано с тем, что шаблон в компоненте `<script setup>` скомпилирован как функция встроенная в ту же область действия кода `<script setup>`. В отличие от доступа к свойствам через `this`, скомпилированный код шаблона может напрямую обращаться к переменным, объявленным внутри `<script setup>`, без промежуточного прокси экземпляра. Это также приводит к лучшей минимизации, поскольку все имена переменных можно безопасно сократить.
+Код, написанный в Composition API и `<script setup>` также более эффективен и удобен для минификации, чем аналогичный в Options API. Это связано с тем, что шаблон в компоненте `<script setup>` скомпилирован как функция, встроенная в ту же область действия кода `<script setup>`. В отличие от доступа к свойствам через `this`, скомпилированный код шаблона может напрямую обращаться к переменным, объявленным внутри `<script setup>`, без промежуточного прокси экземпляра. Это также приводит к лучшей минимизации, поскольку все имена переменных можно безопасно сократить.
 
 ## Связь с Options API {#relationship-with-options-api}
 
@@ -106,7 +106,7 @@ Options API позволяет вам «меньше думать» при на
 
 ### Охватывает ли Composition API все варианты использования? {#does-composition-api-cover-all-use-cases}
 
-Да, с точки зрения логики состояния. При использовании Composition API может понадобиться всего несколько параметров: `props`, `emits`, `name`, and `inheritAttrs`. Если используется `<script setup>`, то `inheritAttrs` обычно является единственным параметром, для которого может потребоваться отдельный обычный `<script>` блок.
+Да, с точки зрения логики состояния. При использовании Composition API может понадобиться всего несколько параметров: `props`, `emits`, `name` и `inheritAttrs`. Если используется `<script setup>`, то `inheritAttrs` обычно является единственным параметром, для которого может потребоваться отдельный обычный `<script>` блок.
 
 :::tip
 С версии 3.3 вы можете напрямую использовать `defineOptions` в `<script setup>` чтобы установить имя компонента или свойство `inheritAttrs`
@@ -118,7 +118,7 @@ Options API позволяет вам «меньше думать» при на
 
 Да. Вы можете использовать Composition API через [`setup()`](/api/composition-api-setup) в компоненте Options API.
 
-Однако мы рекомендуем делать это только в том случае, если у вас есть существующая кодовая база Options API которую необходимо интегрировать с новыми функциями/внешними библиотеками, написанными с помощью Composition API.
+Однако мы рекомендуем делать это только в том случае, если у вас есть существующая кодовая база Options API, которую необходимо интегрировать с новыми функциями/внешними библиотеками, написанными с помощью Composition API.
 
 ### Будет ли Options API объявлен устаревшим? {#will-options-api-be-deprecated}
 
@@ -148,7 +148,7 @@ React Hooks повторно вызываются каждый раз при о
 
 - Вызывает код `setup()` или `<script setup>` только один раз. Это делает код более соответствующим интуитивному использованию идиоматического JavaScript, поскольку не нужно беспокоиться об устаревших замыканиях. Вызовы Composition API также не зависят от порядка вызовов и могут быть условными.
 
-- Vue's во время выполнения автоматически собирает реактивные зависимости, используемые в вычисляемых свойствах и наблюдателях, поэтому нет необходимости вручную объявлять зависимости.
+- Система реактивности среды выполнения Vue автоматически собирает реактивные зависимости, используемые в вычисляемых свойствах и наблюдателях, поэтому нет необходимости вручную объявлять зависимости.
 
 - Нет необходимости вручную кэшировать функции обратного вызова, чтобы избежать ненужных дочерних обновлений. В целом, мелкозернистая система реактивности Vue гарантирует, что дочерние компоненты обновляются только тогда, когда им это необходимо. Оптимизация дочерних обновлений вручную редко беспокоит разработчиков Vue.