Skip to content

Commit d35744d

Browse files
inouetakuyakazupon
authored andcommitted
Japanese Translation: ja/data.md (#25)
* Translate data.md via GitLocalize * Translate data.md via GitLocalize * Fix typos * コード内のコメントを日本語に翻訳した * コード内のコメントの意図をより明確にした * expose はモジュールとしての公開するという意味なので訳を変更した * 原文に ... とあるので一応残しておく
1 parent d1e98d0 commit d35744d

File tree

1 file changed

+231
-0
lines changed

1 file changed

+231
-0
lines changed

Diff for: ja/data.md

+231
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,231 @@
1+
# データのプリフェッチとステート
2+
3+
## データストア
4+
5+
SSR をしているとき、基本的にはアプリケーションの「スナップショット」をレンダリングしています、したがって、アプリケーションがいくつかの非同期データに依存している場合においては、**それらのデータを、レンダリング処理を開始する前にプリフェッチして解決する必要があります**
6+
7+
もうひとつの重要なことは、クライアントサイドでアプリケーションがマウントされる前に、クライアントサイドで同じデータを利用可能である必要があるということです。そうしないと、クライアントサイドが異なるステートを用いてレンダリングしてしまい、ハイドレーションが失敗してしまいます。
8+
9+
この問題に対応するため、フェッチされたデータはビューコンポーネントの外でも存続している必要があります。つまり特定の用途のデータストアもしくは "ステート・コンテナ" に入っている必要があります。サーバーサイドではレンダリングする前にデータをプリフェッチしてストアの中に入れることができます。さらにシリアライズして HTML にステートを埋め込みます。クライアントサイドのストアは、アプリケーションをマウントする前に、埋め込まれたステートを直接取得できます。
10+
11+
このような用途として、公式のステート管理ライブラリである [Vuex](https://github.com/vuejs/vuex/) を使っています。では `store.js` ファイルをつくって、そこに id に基づく item を取得するコードを書いてみましょう:
12+
13+
```js
14+
// store.js
15+
import Vue from 'vue'
16+
import Vuex from 'vuex'
17+
Vue.use(Vuex)
18+
// Promise を返すユニバーサルなアプリケーションを想定しています
19+
// また、実装の詳細は割愛します
20+
import { fetchItem } from './api'
21+
export function createStore () {
22+
return new Vuex.Store({
23+
state: {
24+
items: {}
25+
},
26+
actions: {
27+
fetchItem ({ commit }, id) {
28+
// store.dispatch() 経由でデータがフェッチされたときにそれを知るために、Promise を返します
29+
return fetchItem(id).then(item => {
30+
commit('setItem', { id, item })
31+
})
32+
}
33+
},
34+
mutations: {
35+
setItem (state, { id, item }) {
36+
Vue.set(state.items, id, item)
37+
}
38+
}
39+
})
40+
}
41+
```
42+
43+
そして `app.js` を更新します:
44+
45+
```js
46+
// app.js
47+
import Vue from 'vue'
48+
import App from './App.vue'
49+
import { createRouter } from './router'
50+
import { createStore } from './store'
51+
import { sync } from 'vuex-router-sync'
52+
export function createApp () {
53+
// ルーターとストアのインスタンスを作成します
54+
const router = createRouter()
55+
const store = createStore()
56+
// ルートのステートをストアの一部として利用できるよう同期します
57+
sync(store, router)
58+
// アプリケーションのインスタンスを作成し、ルーターとストアの両方を挿入します
59+
const app = new Vue({
60+
router,
61+
store,
62+
render: h => h(App)
63+
})
64+
// アプリケーション、ルーター、ストアを公開します
65+
return { app, router, store }
66+
}
67+
```
68+
69+
## ロジックとコンポーネントとの結び付き
70+
71+
ではデータをプリフェッチするアクションをディスパッチするコードはどこに置けばよいでしょうか?
72+
73+
フェッチする必要があるデータはアクセスしたルートによって決まります。またそのルートによってどのコンポーネントがレンダリングされるかも決まります。実のところ、与えられたルートに必要とされるデータは、そのルートでレンダリングされるコンポーネントに必要とされるデータでもあるのです。したがって、データをフェッチするロジックはルートコンポーネントの中に置くのが自然でしょう。
74+
75+
ルートコンポーネントではカスタム静的関数 `asyncData` が利用可能です。この関数はそのルートコンポーネントがインスタンス化される前に呼び出されるため `this` にアクセスできないことを覚えておいてください。ストアとルートの情報は引数として渡される必要があります:
76+
77+
```html
78+
<!-- Item.vue -->
79+
<template>
80+
<div data-segment-id="282437">{{ item.title }}</div>
81+
</template>
82+
<script>
83+
export default {
84+
asyncData ({ store, route }) {
85+
// アクションから Promise が返されます
86+
return store.dispatch('fetchItem', route.params.id)
87+
},
88+
computed: {
89+
// ストアのステートから item を表示します
90+
items () {
91+
return this.$store.state.items[this.$route.params.id]
92+
}
93+
}
94+
}
95+
</script>
96+
```
97+
98+
## サーバーサイドのデータ取得
99+
100+
`entry-server.js` において `router.getMatchedComponents()` を使ってルートにマッチしたコンポーネントを取得できます。そしてコンポーネントが `asyncData` を利用可能にしていればそれを呼び出すことができます。そしてレンダリングのコンテキストに解決したステートを付属させる必要があります。
101+
102+
```js
103+
// entry-server.js
104+
import { createApp } from './app'
105+
export default context => {
106+
return new Promise((resolve, reject) => {
107+
const { app, router, store } = createApp()
108+
router.push(context.url)
109+
router.onReady(() => {
110+
const matchedComponents = router.getMatchedComponents()
111+
if (!matchedComponents.length) {
112+
reject({ code: 404 })
113+
}
114+
// マッチしたルートコンポーネントすべての asyncData() を呼び出します
115+
Promise.all(matchedComponents.map(Component => {
116+
if (Component.asyncData) {
117+
return Component.asyncData({
118+
store,
119+
route: router.currentRoute
120+
})
121+
}
122+
})).then(() => {
123+
// すべてのプリフェッチのフックが解決されると、ストアには、
124+
// アプリケーションをレンダリングするために必要とされるステートが入っています。
125+
// ステートを context に付随させ、`template` オプションがレンダラーに利用されると、
126+
// ステートは自動的にシリアライズされ、HTML 内に `window.__INITIAL_STATE__` として埋め込まれます
127+
context.state = store.state
128+
resolve(app)
129+
}).catch(reject)
130+
}, reject)
131+
})
132+
}
133+
```
134+
135+
`template` を使うと `context.state` は自動的に最終的な HTML に `window.__INITIAL__` というかたちのステートとして埋め込まれます。クライアントサイドでは、アプリケーションがマウントされる前に、ストアがそのステートを取得します:
136+
137+
```js
138+
// entry-client.js
139+
const { app, router, store } = createApp()
140+
if (window.__INITIAL_STATE__) {
141+
store.replaceState(window.__INITIAL_STATE__)
142+
}
143+
```
144+
145+
## クライアントサイドのデータ取得
146+
147+
クライアントサイドではデータ取得について 2つの異なるアプローチがあります:
148+
149+
1. **ルートのナビゲーションの前にデータを解決する:**
150+
151+
この方法では、アプリケーションは、遷移先のビューが必要とするデータが解決されるまで、現在のビューを保ちます。良い点は遷移先のビューがデータの準備が整い次第、フルの内容をダイレクトにレンダリングできることです。しかしながら、データの取得に時間がかかるときは、ユーザーは現在のビューで「固まってしまった」と感じてしまうでしょう。そのため、この方法を用いるときにはローディング・インジケーターを表示させることが推奨されます。
152+
153+
この方法は、クライアントサイドでマッチするコンポーネントをチェックし、グローバルなルートのフック内で `asyncData` 関数を実行することにより実装できます。重要なことは、このフックは初期ルートが ready になった後に登録するということです。そうすれば、サーバーサイドで取得したデータをもう一度無駄に取得せずに済みます。
154+
155+
```js
156+
// entry-client.js
157+
// ...関係のないコードは除外します
158+
router.onReady(() => {
159+
// asyncData を扱うためにルーターのフックを追加します。これは初期ルートが解決された後に実行します
160+
// そうすれば(訳注: サーバーサイドで取得したために)既に持っているデータを冗長に取得しなくて済みます
161+
// すべての非同期なコンポーネントが解決されるように router.beforeResolve() を使います
162+
router.beforeResolve((to, from, next) => {
163+
const matched = router.getMatchedComponents(to)
164+
const prevMatched = router.getMatchedComponents(from)
165+
// まだレンダリングされていないコンポーネントにのみ関心を払うため、
166+
// 2つのマッチしたリストに差分が表れるまで、コンポーネントを比較します
167+
let diffed = false
168+
const activated = matched.filter((c, i) => {
169+
return diffed || (diffed = (prevMatched[i] !== c))
170+
})
171+
if (!activated.length) {
172+
return next()
173+
}
174+
// もしローディングインジケーターがあるならば、
175+
// この箇所がローディングインジケーターを発火させるべき箇所です
176+
Promise.all(activated.map(c => {
177+
if (c.asyncData) {
178+
return c.asyncData({ store, route: to })
179+
}
180+
})).then(() => {
181+
// ローディングインジケーターを停止させます
182+
next()
183+
}).catch(next)
184+
})
185+
app.$mount('#app')
186+
})
187+
```
188+
189+
1. **マッチするビューがレンダリングされた後にデータを取得する:**
190+
191+
この方法ではビューコンポーネントの `beforeMount` 関数内にクライアントサイドでデータを取得するロジックを置きます。こうすればルートのナビゲーションが発火したらすぐにビューを切り替えられます。そうすればアプリケーションはよりレスポンスが良いと感じられるでしょう。しかしながら、遷移先のビューはレンダリングした時点ではフルのデータを持っていません。したがって、この方法を使うコンポーネントの各々がローディング中か否かの状態を持つ必要があります。
192+
193+
この方法はクライアントサイド限定のグローバルな mixin で実装できます:
194+
195+
```js
196+
Vue.mixin({
197+
beforeMount () {
198+
const { asyncData } = this.$options
199+
if (asyncData) {
200+
// データが準備できた後に、コンポーネント内で `this.dataPromise.then(...)` して
201+
// 他のタスクを実行できるようにするため、Promise にフェッチ処理を割り当てます
202+
this.dataPromise = asyncData({
203+
store: this.$store,
204+
route: this.$route
205+
})
206+
}
207+
}
208+
})
209+
```
210+
211+
これら 2つの方法のどちらを選ぶかは、究極的には異なる UX のどちらを選ぶかの判断であり、構築しようとしているアプリケーションの実際のシナリオに基づいて選択されるべきものです。しかし、どちらの方法を選択したかにかかわらず、ルートコンポーネントが再利用されたとき(つまりルートは同じだがパラメーターやクエリが変わったとき。例えば `user/1` から `user/2`) へ変わったとき)には `asyncData` 関数は呼び出されるようにすべきです。これはクライアントサイド限定のグローバルな mixin でハンドリングできます:
212+
213+
```js
214+
Vue.mixin({
215+
beforeRouteUpdate (to, from, next) {
216+
const { asyncData } = this.$options
217+
if (asyncData) {
218+
asyncData({
219+
store: this.$store,
220+
route: to
221+
}).then(next).catch(next)
222+
} else {
223+
next()
224+
}
225+
}
226+
})
227+
```
228+
229+
---
230+
231+
ふぅ、コードが長いですね。これはどうしてかというと、ユニバーサルなデータ取得は、大抵の場合、サーバーサイドでレンダリングするアプリケーションの最も複雑な問題であり、また、今後、スムーズに開発を進めていくための下準備をしているためです。一旦ひな形が準備できてしまえば、あとは、それぞれのコンポーネントを記述していく作業は、実際のところ実に楽しいものになるはずです。

0 commit comments

Comments
 (0)