Merge remote-tracking branch 'upstream/master' into working

Author: MachinisteWeb

ja/bundle-renderer.md

@@ -35,7 +35,6 @@ server.get('*', (req, res) => {
   const context = { url: req.url }
   // バンドルを実行することで自動作成されるため、ここでアプリケーションを渡す必要はありません
   // 今、私たちのサーバーはVueアプリから切り離されています！
-app!
   renderer.renderToString(context, (err, html) => {
     // ハンドリングエラー ...
     res.end(html)

ja/data.md

@@ -97,7 +97,7 @@ export default {
 
 ## サーバーサイドのデータ取得
 
-`entry-server.js` において `router.getMatchedComponents()` を使ってルートにマ一致したコンポーネントを取得できます。そしてコンポーネントが `asyncData` を利用可能にしていればそれを呼び出すことができます。そして描画のコンテキストに解決した状態を付属させる必要があります。
+`entry-server.js` において `router.getMatchedComponents()` を使ってルートに一致したコンポーネントを取得できます。そしてコンポーネントが `asyncData` を利用可能にしていればそれを呼び出すことができます。そして描画のコンテキストに解決した状態を付属させる必要があります。
 
 ```js
 // entry-server.js

ja/head.md

@@ -2,7 +2,7 @@
 
 アセットの挿入と同様に、ヘッド (Head) の管理も同じ考えに追従しています。つまり、コンポーネントのライフサイクルの描画 `context` に動的にデータを付随させ、そして `template` 内にデータを展開 (interpolate) できるという考えです。
 
-> バージョン >=2.3.2 では、`this.$ssrContext` としてコンポーネントにおいて SSR コンテキストに直接アクセスできます。古いバージョンでは、`createApp()` によって手動で SSR コンテストを渡して注入し、ルート (root) インスタンスの `$options` に公開する必要がります。子は、`this.$root.$options.ssrContext` を介してそれにアクセスすることができます。
+> バージョン >=2.3.2 では、`this.$ssrContext` としてコンポーネントにおいて SSR コンテキストに直接アクセスできます。古いバージョンでは、`createApp()` によって手動で SSR コンテキストを渡して注入し、ルート (root) インスタンスの `$options` に公開する必要があります。子は、`this.$root.$options.ssrContext` を介してそれにアクセスすることができます。
 
 タイトルを管理する単純な mixin を書くことができます:
 

ru/api.md

@@ -131,7 +131,7 @@ const renderer = createBundleRenderer(serverBundle, { ... })
   - используется только в `createBundleRenderer`
   - Ожидается: `boolean | 'once'` (`'once'` поддерживается только с версии 2.3.1+)
 
-  По умолчанию, рендерер сборки будет создавать новый контекст V8 для каждого рендеринга и повторно исполнять всю сборку. Это имеет некоторые преимущества — например, код приложения изолирован от процесса сервера и не нужно беспокоиться [о проблеме «синглетона с состоянием»](./structure.md#avoid-stateful-singletons), которая упоминалась ранее в руководстве. Однако этот режим требует значительных затрат производительности, поскольку повторное выполнение сборки обходится дорого, особенно когда приложение становится большим.
+  По умолчанию, рендерер сборки будет создавать новый контекст V8 для каждого рендеринга и повторно исполнять всю сборку. Это имеет некоторые преимущества — например, код приложения изолирован от процесса сервера и не нужно беспокоиться [о проблеме «синглтона с состоянием»](./structure.md#avoid-stateful-singletons), которая упоминалась ранее в руководстве. Однако этот режим требует значительных затрат производительности, поскольку повторное выполнение сборки обходится дорого, особенно когда приложение становится большим.
 
   По умолчанию эта опция имеет значение `true` для обеспечения обратной совместимости, но рекомендуется использовать `runInNewContext: false` или `runInNewContext: 'once'` всегда, когда это возможно.
 

ru/structure.md

@@ -1,8 +1,8 @@
 # Структура исходного кода
 
-## Избегайте синглетонов с состоянием
+## Избегайте синглтонов с состоянием
 
-При написании кода для клиентской стороны мы привыкли к тому, что наш код каждый раз будет выполняться в новом контексте. Однако сервер Node.js является длительным процессом (long-running process). Поэтому когда наш код потребуется, он будет выполнен один раз и останется в памяти. Это означает, что если вы создаёте объект синглетон, он будет использоваться для всех входящих запросов.
+При написании кода для клиентской стороны мы привыкли к тому, что наш код каждый раз будет выполняться в новом контексте. Однако сервер Node.js является длительным процессом (long-running process). Поэтому когда наш код потребуется, он будет выполнен один раз и останется в памяти. Это означает, что если вы создаёте объект синглтон, он будет использоваться для всех входящих запросов.
 
 Как видно из простого примера, мы **создаём новый корневой экземпляр Vue для каждого запроса**. Это схоже с тем, когда каждый пользователь будет использовать свежий экземпляр приложения в своём браузере. Если мы будем использовать общий экземпляр для нескольких запросов, то это быстро приведёт к загрязнению состояния.
 

ru/universal.md

@@ -1,6 +1,6 @@
 # Написание универсального кода
 
-Прежде чем идти дальше, давайте немного обсудим ограничения при написании «универсального» кода — кода, который выполняется как на сервере, так и на клиенте. Из-за различий в API платформы, поведение нашего кода будет отличаться при работе в разных средах выполнения. Здесь мы рассмотрим ключевые моменты, которые нужно вам нужно знать.
+Прежде чем идти дальше, давайте немного обсудим ограничения при написании «универсального» кода — кода, который выполняется как на сервере, так и на клиенте. Из-за различий в API платформы, поведение нашего кода будет отличаться при работе в разных средах выполнения. Здесь мы рассмотрим ключевые моменты, которые вам нужно знать.
 
 ## Реактивность данных на сервере
 
@@ -22,7 +22,7 @@
 
 Для API только для браузеров общий подход — ленивый (lazy) доступ к ним, внутри хуков жизненного цикла только для клиентской стороны.
 
-Обратите внимание, что если сторонняя библиотека не была написана с расчётом на универсальное использование, её может быть сложно интегрировать в приложение с серверным рендерингом. Вы *могли бы* заставить её работать, например создавая моки некоторых глобальных переменных, но это будет грязным хаком и может помешать коду обнаружения окружения в других библиотеках.
+Обратите внимание, если сторонняя библиотека не была написана с расчётом на универсальное использование, её может быть сложно интегрировать в приложение с серверным рендерингом. Вы *могли бы* заставить её работать, например создавая моки некоторых глобальных переменных, но это будет грязным хаком и может помешать коду обнаружения окружения в других библиотеках.
 
 ## Пользовательские директивы