You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: ja/data.md
+22-22
Original file line number
Diff line number
Diff line change
@@ -2,13 +2,13 @@
2
2
3
3
## データストア
4
4
5
-
During SSR, we are essentially rendering a "snapshot" of our app, so if the app relies on some asynchronous data, **these data need to be pre-fetched and resolved before we start the rendering process**.
5
+
SSR をしているとき、基本的にはアプリケーションの「スナップショット」をレンダリングしています、したがって、アプリケーションがいくつかの非同期データに依存している場合においては、**それらのデータを、レンダリング処理を開始する前にプリフェッチして解決する必要があります**。
6
6
7
-
Another concern is that on the client, the same data needs to be available before we mount the client side app - otherwise the client app would render using different state and the hydration would fail.
To address this, the fetched data needs to live outside the view components, in a dedicated data store, or a "state container". On the server, we can pre-fetch and fill data into the store before rendering. In addition, we will serialize and inline the state in the HTML. The client-side store can directly pick up the inlined state before we mount the app.
We will be using the official state management library [Vuex](https://github.com/vuejs/vuex/)for this purpose. Let's create a `store.js`file, with some mocked logic for fetching an item based on an id:
11
+
このような用途として、公式のステート管理ライブラリである [Vuex](https://github.com/vuejs/vuex/)を使っています。では `store.js`ファイルをつくって、そこに id に基づく item を取得するコードを書いてみましょう:
12
12
13
13
```js
14
14
// store.js
@@ -41,7 +41,7 @@ export function createStore () {
41
41
}
42
42
```
43
43
44
-
And update `app.js`:
44
+
そして `app.js` を更新します:
45
45
46
46
```js
47
47
// app.js
@@ -67,13 +67,13 @@ export function createApp () {
67
67
}
68
68
```
69
69
70
-
## Logic Collocation with Components
70
+
## ロジックとコンポーネントとの結び付き
71
71
72
-
So, where do we place the code that dispatches the data-fetching actions?
72
+
ではデータをプリフェッチするアクションをディスパッチするコードはどこに書けばよいでしょうか？
73
73
74
-
The data we need to fetch is determined by the route visited - which also determines what components are rendered. In fact, the data needed for a given route is also the data needed by the components rendered at that route. So it would be natural to place the data fetching logic inside route components.
We will expose a custom static function `asyncData`on our route components. Note because this function will be called before the components are instantiated, it doesn't have access to `this`. The store and route information needs to be passed in as arguments:
In `entry-server.js`we can get the components matched by a route with `router.getMatchedComponents()`, and call `asyncData`if the component exposes it. Then we need to attach resolved state to the render context.
When using `template`, `context.state`will automatically be embedded in the final HTML as`window.__INITIAL__`state. On the client, the store should pick up the state before mounting the application:
137
+
`template` を使うと `context.state`は自動的に最終的な HTML に`window.__INITIAL__`というかたちのステートとして埋め込まれます。クライアントサイドでは、アプリケーションがマウントされる前に、ストアがそのステートを取得します:
138
138
139
139
```js
140
140
// entry-client.js
@@ -144,15 +144,15 @@ if (window.__INITIAL_STATE__) {
144
144
}
145
145
```
146
146
147
-
## Client Data Fetching
147
+
## クライアントサイドのデータ取得
148
148
149
-
On the client, there are two different approaches for handling data fetching:
149
+
クライアントサイドではデータ取得について 2つの異なるアプローチがあります:
150
150
151
-
1.**Resolve data before route navigation:**
151
+
1.**ルートのナビゲーションの前にデータを解決する:**
152
152
153
-
With this strategy, the app will stay on the current view until the data needed by the incoming view has been resolved. The benefit is that the incoming view can directly render the full content when it's ready, but if the data fetching takes a long time, the user will feel "stuck" on the current view. It is therefore recommended to provide a data loading indicator if using this strategy.
We can implement this strategy on the client by checking matched components and invoking their `asyncData`function inside a global route hook. Note we should register this hook after the initial route is ready so that we don't unnecessarily fetch the server-fetched data again.
@@ -188,11 +188,11 @@ On the client, there are two different approaches for handling data fetching:
188
188
})
189
189
```
190
190
191
-
1.**Fetch data after the matched view is rendered:**
191
+
1.**マッチするビューがレンダリングされた後にデータを取得する:**
192
192
193
-
This strategy places the client-side data-fetching logic in a view component's `beforeMount`function. This allows the views to switch instantly when a route navigation is triggered, so the app feels a bit more responsive. However, the incoming view will not have the full data available when it's rendered. It is therefore necessary to have a conditional loading state for each view component that uses this strategy.
This can be achieved with a client-only global mixin:
195
+
この方法はクライアントサイド限定のグローバルな mixin で実装できます:
196
196
197
197
```js
198
198
Vue.mixin({
@@ -211,7 +211,7 @@ On the client, there are two different approaches for handling data fetching:
211
211
})
212
212
```
213
213
214
-
The two strategies are ultimately different UX decisions and should be picked based on the actual scenario of the app you are building. But regardless of which strategy you pick, the `asyncData` function should also be called when a route component is reused (same route, but params or query changed. e.g. from `user/1`to`user/2`). We can also handle this with a client-only global mixin:
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.
0 commit comments