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: docs/api/README.md
+20Lines changed: 20 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -287,6 +287,26 @@ As an example, check out [`v-show`'s server-side implementation](https://github.
287
287
288
288
Provide a custom serializer function for `context.state`. Since the serialized state will be part of your final HTML, it is important to use a function that properly escapes HTML characters for security reasons. The default serializer is [serialize-javascript](https://github.com/yahoo/serialize-javascript) with `{ isJSON:true }`.
289
289
290
+
## Server-only Component Options
291
+
292
+
### serverCacheKey
293
+
294
+
- **Type:** `(props) => any`
295
+
296
+
Return the cache key for the component based on incoming props. Does NOT have access to `this`.
297
+
298
+
Since 2.6, you can explicitly bail out of caching by returning `false`.
299
+
300
+
See more details in [Component-level Caching](../guide/caching.html#component-level-caching).
301
+
302
+
### serverPrefetch
303
+
304
+
- **Type:** `() =>Promise<any>`
305
+
306
+
Fetch async data during server side rendering. It should store fetched data into a global store and return a Promise. The server renderer will wait on this hook until the Promise is resolved. This hook has access to the component instance via `this`.
307
+
308
+
See more details in [Data Fetching](../guide/data.html).
309
+
290
310
## webpack Plugins
291
311
292
312
The webpack plugins are provided as standalone files and should be required directly:
Copy file name to clipboardExpand all lines: docs/guide/data.md
+12-8Lines changed: 12 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -87,13 +87,13 @@ So, where do we place the code that dispatches the data-fetching actions?
87
87
88
88
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.
89
89
90
-
We will use the `ssrPrefetch` option in our components. This option is recognized by the server renderer and will be pause the component render until the promise it returns is resolved. Since the component instance is already created at this point, it has access to `this`.
90
+
We will use the `serverPrefetch` option (new in 2.6.0+) in our components. This option is recognized by the server renderer and will pause the rendering until the promise it returns is resolved. This allows us to "wait" on async data during the rendering process.
91
91
92
92
::: tip
93
-
You can use `ssrPrefetch` in any component, not just the route-level components.
93
+
You can use `serverPrefetch` in any component, not just the route-level components.
94
94
:::
95
95
96
-
Here is an example `Item.vue` component that is rendered at the `'/item/:id'` route:
96
+
Here is an example `Item.vue` component that is rendered at the `'/item/:id'` route. Since the component instance is already created at this point, it has access to `this`:
97
97
98
98
```html
99
99
<!-- Item.vue -->
@@ -113,7 +113,7 @@ export default {
113
113
114
114
// Server-side only
115
115
// This will be called by the server renderer automatically
116
-
ssrPrefetch () {
116
+
serverPrefetch () {
117
117
// return the Promise from the action
118
118
// so that the component waits before rendering
119
119
returnthis.fetchItem()
@@ -142,9 +142,13 @@ export default {
142
142
You should check if the component was server-side rendered in the `mounted` hook to avoid executing the logic twice.
143
143
:::
144
144
145
-
## Server Data Fetching
145
+
::: tip
146
+
You may find the same `fetchItem()` logic repeated multiple times (in `serverPrefetch`, `mounted` and `watch` callbacks) in each component - it is recommended to create your own abstraction (e.g. a mixin or a plugin) to simplify such code.
147
+
:::
146
148
147
-
In `entry-server.js`, we will set the store state in the render context after the app is finished rendering, thanks to the `context.rendered` hook recognized by the server renderer.
149
+
## Final State Injection
150
+
151
+
Now we know that the rendering process will wait for data fetching in our components, how do we know when it is "done"? In order to do that, we need to attach a `rendered` callback to the render context (also new in 2.6), which the server renderer will call when the entire rendering process is finished. At this moment, the store should have been filled with the final state. We can then inject it on to the context in that callback:
148
152
149
153
```js
150
154
// entry-server.js
@@ -233,7 +237,7 @@ export default {
233
237
},
234
238
235
239
// Server-side only
236
-
ssrPrefetch () {
240
+
serverPrefetch () {
237
241
this.registerFoo()
238
242
returnthis.fooInc()
239
243
},
@@ -243,7 +247,7 @@ export default {
243
247
// We already incremented 'count' on the server
244
248
// We know by checking if the 'foo' state already exists
0 commit comments