diff --git a/ru/data.md b/ru/data.md
index b47b31a7..809b78d6 100644
--- a/ru/data.md
+++ b/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.
+
 ---
 
 Фух, это было много кода! Это связано с тем, что универсальная загрузка данных является, вероятно, самой сложной проблемой в приложении с рендерингом на стороне сервера, и таким образом мы закладываем хороший фундамент для облегчения дальнейшей разработки. После создания такой заготовки, создание отдельных компонентов будет приятным занятием.
diff --git a/ru/universal.md b/ru/universal.md
index edcd436f..60179795 100644
--- a/ru/universal.md
+++ b/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, и наоборот.