1
0
Эх сурвалжийг харах

docs(ru): fix punctuation and typos (#1714)

Alexey 5 жил өмнө
parent
commit
e52756cab0

+ 2 - 2
docs/ru/README.md

@@ -48,7 +48,7 @@ new Vue({
 
 
 Решая первую проблему, придётся передавать одни и те же данные входными параметрами в глубоко вложенные компоненты. Это часто сложно и утомительно, а для соседних компонентов такое и вовсе не сработает. Решая вторую проблему, можно прийти к таким решениям, как обращение по ссылкам к родительским/дочерним экземплярам или попыткам изменять и синхронизировать несколько копий состояния через события. Оба подхода хрупки и быстро приводят к появлению кода, который невозможно поддерживать.
 Решая первую проблему, придётся передавать одни и те же данные входными параметрами в глубоко вложенные компоненты. Это часто сложно и утомительно, а для соседних компонентов такое и вовсе не сработает. Решая вторую проблему, можно прийти к таким решениям, как обращение по ссылкам к родительским/дочерним экземплярам или попыткам изменять и синхронизировать несколько копий состояния через события. Оба подхода хрупки и быстро приводят к появлению кода, который невозможно поддерживать.
 
 
-Так почему бы не вынести всё общее состояние приложения из компонентов и управлять им в глобальном синглтоне? При этом наше дерево компонентов становится одним большим «представлением» и любой компонент может получить доступ к состоянию приложения или вызывать действия для изменения состояния, независимо от того, где они находятся в дереве!
+Так почему бы не вынести всё общее состояние приложения из компонентов и управлять им в глобальном синглтоне? При этом наше дерево компонентов становится одним большим «представлением», и любой компонент может получить доступ к состоянию приложения или вызывать действия для изменения состояния, независимо от того, где они находятся в дереве!
 
 
 Чётко определяя и разделяя концепции, возникающие при управлении состоянием, и требуя соблюдения определённых правил, которые поддерживают независимость между представлениями и состояниями, мы лучше структурируем код и облегчаем его поддержку.
 Чётко определяя и разделяя концепции, возникающие при управлении состоянием, и требуя соблюдения определённых правил, которые поддерживают независимость между представлениями и состояниями, мы лучше структурируем код и облегчаем его поддержку.
 
 
@@ -60,7 +60,7 @@ new Vue({
 
 
 ### Когда следует использовать Vuex?
 ### Когда следует использовать Vuex?
 
 
-Vuex помогает управлять совместно используемым состоянием, ценой привнесения новых концепций и вспомогательного кода. Компромисс, когда кратковременная продуктивность страдает на благо долгосрочной.
+Vuex помогает управлять совместно используемым состоянием ценой привнесения новых концепций и вспомогательного кода. Компромисс, когда кратковременная продуктивность страдает на благо долгосрочной.
 
 
 Если ещё не приходилось создавать крупные SPA и вы лишь знакомитесь с Vuex, это может показаться многословным и сложным. Всё в порядке — простые приложения могут легко обходиться и без Vuex. Возможно, будет достаточно простого паттерна [глобальной шины событий](https://ru.vuejs.org/v2/guide/state-management.html#Простой-контейнер-состояния-с-нуля). Но если вы создаёте SPA среднего или крупного размера, то, скорее всего, уже сталкивались с ситуациями, которые заставляли задуматься о том, как лучше управлять состоянием вне компонентов Vue, а Vuex в таком случае может стать вполне естественным следующим шагом. Есть хорошая цитата от Дэна Абрамова, автора Redux:
 Если ещё не приходилось создавать крупные SPA и вы лишь знакомитесь с Vuex, это может показаться многословным и сложным. Всё в порядке — простые приложения могут легко обходиться и без Vuex. Возможно, будет достаточно простого паттерна [глобальной шины событий](https://ru.vuejs.org/v2/guide/state-management.html#Простой-контейнер-состояния-с-нуля). Но если вы создаёте SPA среднего или крупного размера, то, скорее всего, уже сталкивались с ситуациями, которые заставляли задуматься о том, как лучше управлять состоянием вне компонентов Vue, а Vuex в таком случае может стать вполне естественным следующим шагом. Есть хорошая цитата от Дэна Абрамова, автора Redux:
 
 

+ 1 - 1
docs/ru/api/README.md

@@ -241,7 +241,7 @@ store.subscribeAction({
 
 
 * `hasModule(path: string | Array<string>)`
 * `hasModule(path: string | Array<string>)`
 
 
-Проверка не зарегистрирован ли уже модуль с заданным именем. [Подробнее](../guide/modules.md#динамическая-регистрация-модуnей)
+Проверка, не зарегистрирован ли уже модуль с заданным именем. [Подробнее](../guide/modules.md#динамическая-регистрация-модуnей)
 
 
 > Добавлено в версии 3.2.0
 > Добавлено в версии 3.2.0
 
 

+ 1 - 1
docs/ru/guide/README.md

@@ -37,7 +37,7 @@ store.commit('increment')
 console.log(store.state.count) // -> 1
 console.log(store.state.count) // -> 1
 ```
 ```
 
 
-Запомните, причина, по которой мы вызываем мутацию, вместо изменения `store.state.count` напрямую, в том, что мы хотим явным образом отслеживать её. Это простое соглашение делает наше намерение более явным, что упрощает понимание происходящих изменений состояния приложения при чтении кода. Кроме того, это позволяет использовать инструменты для отслеживания каждой мутации, создания снимков состояния или даже использования «машины времени» для отладки.
+Запомните, причина, по которой мы вызываем мутацию вместо изменения `store.state.count` напрямую, в том, что мы хотим явным образом отслеживать её. Это простое соглашение делает наше намерение более явным, что упрощает понимание происходящих изменений состояния приложения при чтении кода. Кроме того, это позволяет использовать инструменты для отслеживания каждой мутации, создания снимков состояния или даже использования «машины времени» для отладки.
 
 
 Использование состояния хранилища в компоненте предполагает просто возврат необходимой части состояния в вычисляемом свойстве, поскольку состояние хранилища реактивно. Инициирование изменений — это просто запуск мутаций в методах компонентов.
 Использование состояния хранилища в компоненте предполагает просто возврат необходимой части состояния в вычисляемом свойстве, поскольку состояние хранилища реактивно. Инициирование изменений — это просто запуск мутаций в методах компонентов.
 
 

+ 1 - 1
docs/ru/guide/actions.md

@@ -47,7 +47,7 @@ actions: {
 store.dispatch('increment');
 store.dispatch('increment');
 ```
 ```
 
 
-На первый взгляд может выглядеть глупо: если мы хотим увеличить значение count, почему бы просто не вызвать `store.commit('increment')` напрямую? Помните что **мутации должны быть синхронными**. Для действий такого ограничения нет. Внутри действий можно выполнять **асинхронные** операции:
+На первый взгляд может выглядеть глупо: если мы хотим увеличить значение count, почему бы просто не вызвать `store.commit('increment')` напрямую? Помните, что **мутации должны быть синхронными**. Для действий такого ограничения нет. Внутри действий можно выполнять **асинхронные** операции:
 
 
 ```js
 ```js
 actions: {
 actions: {

+ 3 - 3
docs/ru/guide/modules.md

@@ -33,7 +33,7 @@ store.state.b // -> состояние модуля `moduleB`
 
 
 ### Локальное состояние модулей
 ### Локальное состояние модулей
 
 
-Первым аргументом, который получают мутации и геттеры, будет **локальное состояние модуля**.
+Первым аргументом, который получает мутации и геттеры, будет **локальное состояние модуля**.
 
 
 ```js
 ```js
 const moduleA = {
 const moduleA = {
@@ -85,7 +85,7 @@ const moduleA = {
 
 
 По умолчанию действия, мутации и геттеры внутри модулей регистрируются в **глобальном пространстве имён** — это позволяет нескольким модулям реагировать на тот же тип мутаций/действий.
 По умолчанию действия, мутации и геттеры внутри модулей регистрируются в **глобальном пространстве имён** — это позволяет нескольким модулям реагировать на тот же тип мутаций/действий.
 
 
-Если вы хотите сделать модули более самодостаточными и готовыми для переиспользования, вы можете создать его с собственным пространством имён, указав опцию `namespaced: true`. Когда модуль будет зарегистрирован, все его геттеры, действия и мутации будут автоматически связаны с этим пространством имён, основываясь на пути по которому зарегистрирован модуль. Например:
+Если вы хотите сделать модули более самодостаточными и готовыми для переиспользования, вы можете создать его с собственным пространством имён, указав опцию `namespaced: true`. Когда модуль будет зарегистрирован, все его геттеры, действия и мутации будут автоматически связаны с этим пространством имён, основываясь на пути, по которому зарегистрирован модуль. Например:
 
 
 ```js
 ```js
 const store = new Vuex.Store({
 const store = new Vuex.Store({
@@ -298,7 +298,7 @@ store.registerModule(['nested', 'myModule'], {
 
 
 Удалить динамически зарегистрированный модуль можно с помощью `store.unregisterModule(moduleName)`. Обратите внимание, что статические (определённые на момент создания хранилища) модули при помощи этого метода удалить не получится.
 Удалить динамически зарегистрированный модуль можно с помощью `store.unregisterModule(moduleName)`. Обратите внимание, что статические (определённые на момент создания хранилища) модули при помощи этого метода удалить не получится.
 
 
-Обратите внимание, что можно проверить зарегистрирован ли уже модуль с заданным именем с помощью метода `store.hasModule(moduleName)`.
+Обратите внимание, что можно проверить, зарегистрирован ли уже модуль с заданным именем с помощью метода `store.hasModule(moduleName)`.
 
 
 #### Сохранение состояния
 #### Сохранение состояния