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

# Conflicts:
#	en/universal.md

Author: MachinisteWeb

en/api.md

@@ -82,9 +82,8 @@ See [Introducing the Server Bundle](./bundle-renderer.md) and [Build Configurati
 - #### `clientManifest`
 
   - 2.3.0+
-  - only used in `createBundleRenderer`
 
-  Provide a client build manifest object generated by `vue-server-renderer/server-plugin`. The client manifest provides the bundle renderer with the proper information for automatic asset injection into the HTML template. For more details, see [Generating clientManifest](./build-config.md#generating-clientmanifest).
+  Provide a client build manifest object generated by `vue-server-renderer/client-plugin`. The client manifest provides the bundle renderer with the proper information for automatic asset injection into the HTML template. For more details, see [Generating clientManifest](./build-config.md#generating-clientmanifest).
 
 - #### `inject`
 

en/bundle-renderer.md

@@ -38,7 +38,7 @@ const renderer = createBundleRenderer(serverBundle, {
 // inside a server handler...
 server.get('*', (req, res) => {
   const context = { url: req.url }
-  // No need to pass an app here because it is auto-created by the
+  // No need to pass an app here because it is auto-created by
   // executing the bundle. Now our server is decoupled from our Vue app!
   renderer.renderToString(context, (err, html) => {
     // handle error...

en/data.md

@@ -97,7 +97,7 @@ export default {
 
   computed: {
     // display the item from store state.
-    items () {
+    item () {
       return this.$store.state.items[this.$route.params.id]
     }
   }
@@ -254,6 +254,63 @@ Vue.mixin({
 })
 ```
 
+## Store Code Splitting
+
+In a large application, our vuex store will likely be split into multiple modules. Of course, it is also possible to code-split these modules into corresponding route component chunks. Suppose we have the following store module:
+
+``` js
+// store/modules/foo.js
+export default {
+  namespaced: true,
+  // IMPORTANT: state must be a function so the module can be
+  // instantiated multiple times
+  state: () => ({
+    count: 0
+  }),
+  actions: {
+    inc: ({ commit }) => commit('inc')
+  },
+  mutations: {
+    inc: state => state.count++
+  }
+}
+```
+
+We can use `store.registerModule` to lazy-register this module in a route component's `asyncData` hook:
+
+``` html
+// inside a route component
+<template>
+  <div>{{ fooCount }}</div>
+</template>
+
+<script>
+// import the module here instead of in `store/index.js`
+import fooStoreModule from '../store/modules/foo'
+
+export default {
+  asyncData ({ store }) {
+    store.registerModule('foo', fooStoreModule)
+    return store.dispatch('foo/inc')
+  },
+
+  // IMPORTANT: avoid duplicate module registration on the client
+  // when the route is visited multiple times.
+  destroyed () {
+    this.$store.unregisterModule('foo')
+  },
+
+  computed: {
+    fooCount () {
+      return this.$store.state.foo.count
+    }
+  }
+}
+</script>
+```
+
+Because the module is now a dependency of the route component, it will be moved into the route component's async chunk by webpack.
+
 ---
 
 Phew, that was a lot of code! This is because universal data-fetching is probably the most complex problem in a server-rendered app and we are laying the groundwork for easier further development. Once the boilerplate is set up, authoring individual components will be actually quite pleasant.

en/universal.md

@@ -12,6 +12,8 @@ Etant donné que le processus de rendu actuel doit être déterministe, nous all
 
 Vu qu'il n'y a pas de mises à jour dynamiques, de tous les hooks de cycles de vie, seuls `beforeCreate` et `created` seront appelés pendant le rendu côté serveur. Cela signifie que tout code présent dans d'autres hooks tels que `beforeMount` ou `mounted` sera exécuté uniquement côté client.
 
+Une autre chose a noter est que vous devriez éviter la création d'effets de bord globaux dans `beforeCreate` et `created` comme ceux, par exemple, dus aux timers avec `setInterval`. Nous pouvons mettre en place des timers seulement dans du code côté client qui seront arrêtés pendant les phases `beforeDestroy` et `destroyed`. Cependant, comme ces hooks ne sont jamais appelés pendant le SSR, les timers vont continuer de tourner éternellement. Pour éviter cela, déplacez ce type d'effet de bord dans les hooks `beforeMount` ou `mounted`.
+
 ## Accès aux APIs spécifiques à la plateforme
 
 Le code universel ne peut pas accéder aux APIs spécifiques à une plateforme. Ainsi, si votre code utilise directement les variables globales exclusives au navigateur comme `window` ou `document`, elles lèveront des erreurs si elles sont exécutées sur Node.js, et vice-versa.

ru/data.md

@@ -97,7 +97,7 @@ export default {
 
   computed: {
     // отображаем элемент из состояния хранилища.
-    items () {
+    item () {
       return this.$store.state.items[this.$route.params.id]
     }
   }
@@ -254,6 +254,63 @@ Vue.mixin({
 })
 ```
 
+## Разделение кода хранилища
+
+В большом приложении хранилище Vuex будет скорее всего разделено на несколько модулей. Конечно, также можно разделить код этих модулей на соответствующие фрагменты компонента маршрута. Предположим, что у нас есть следующий модуль хранилища:
+
+``` js
+// store/modules/foo.js
+export default {
+  namespaced: true,
+  // ВАЖНО: state должен быть функцией, чтобы
+  // модуль мог инстанцироваться несколько раз
+  state: () => ({
+    count: 0
+  }),
+  actions: {
+    inc: ({ commit }) => commit('inc')
+  },
+  mutations: {
+    inc: state => state.count++
+  }
+}
+```
+
+Мы можем использовать `store.registerModule` для lazy-регистрации этого модуля в хуке `asyncData` компонента маршрута:
+
+``` html
+// внутри компонента маршрута
+<template>
+  <div>{{ fooCount }}</div>
+</template>
+
+<script>
+// импортируем модуль здесь, а не в `store/index.js`
+import fooStoreModule from '../store/modules/foo'
+
+export default {
+  asyncData ({ store }) {
+    store.registerModule('foo', fooStoreModule)
+    return store.dispatch('foo/inc')
+  },
+
+  // ВАЖНО: избегайте дублирования регистрации модуля на клиенте
+  // когда маршрут посещается несколько раз.
+  destroyed () {
+    this.$store.unregisterModule('foo')
+  },
+
+  computed: {
+    fooCount () {
+      return this.$store.state.foo.count
+    }
+  }
+}
+</script>
+```
+
+Поскольку модуль теперь является зависимостью компонента маршрута, он будет перемещён в асинхронный фрагмент компонента маршрута с помощью Webpack.
+
 ---
 
 Фух, это было много кода! Это связано с тем, что универсальная загрузка данных является, вероятно, самой сложной проблемой в приложении с рендерингом на стороне сервера, и таким образом мы закладываем хороший фундамент для облегчения дальнейшей разработки. После создания такой заготовки, создание отдельных компонентов будет приятным занятием.

ru/universal.md

@@ -12,6 +12,8 @@
 
 Так как динамических обновлений нет, из всех хуков жизненного цикла будут вызваны только `beforeCreate` и `created` во время серверного рендеринга (SSR). Это означает, что код внутри любых других хуков жизненного цикла, таких как `beforeMount` или `mounted`, будет выполняться только на клиенте.
 
+Стоит ещё отметить, что вам следует избегать кода, который производит глобальные побочные эффекты (side effects) в хуках `beforeCreate` и `created`, например устанавливая таймеры с помощью `setInterval`. В коде на стороне клиента мы можем установить таймер, а затем остановить его в `beforeDestroy` или `destroyed`. Но, поскольку хуки уничтожения не будут вызываться во время SSR, таймеры останутся навсегда. Чтобы избежать этого, переместите такой код в `beforeMount` или `mounted`.
+
 ## Доступ к специализированному API платформы
 
 Универсальный код не может использовать API специализированное для какой-то конкретной платформы (platform-specific APIs), потому что если ваш код будет использовать глобальные переменные браузеров `window` или `document`, то возникнут ошибки при выполнении в Node.js, и наоборот.