Skip to content

Commit 3a55f08

Browse files
committed
2.6: serverPrefetch updates
1 parent d93844e commit 3a55f08

File tree

2 files changed

+32
-8
lines changed

2 files changed

+32
-8
lines changed

docs/api/README.md

Lines changed: 20 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -287,6 +287,26 @@ As an example, check out [`v-show`'s server-side implementation](https://github.
287287
288288
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 }`.
289289
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+
290310
## webpack Plugins
291311
292312
The webpack plugins are provided as standalone files and should be required directly:

docs/guide/data.md

Lines changed: 12 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -87,13 +87,13 @@ So, where do we place the code that dispatches the data-fetching actions?
8787

8888
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.
8989

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.
9191

9292
::: 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.
9494
:::
9595

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`:
9797

9898
``` html
9999
<!-- Item.vue -->
@@ -113,7 +113,7 @@ export default {
113113
114114
// Server-side only
115115
// This will be called by the server renderer automatically
116-
ssrPrefetch () {
116+
serverPrefetch () {
117117
// return the Promise from the action
118118
// so that the component waits before rendering
119119
return this.fetchItem()
@@ -142,9 +142,13 @@ export default {
142142
You should check if the component was server-side rendered in the `mounted` hook to avoid executing the logic twice.
143143
:::
144144

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+
:::
146148

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:
148152

149153
``` js
150154
// entry-server.js
@@ -233,7 +237,7 @@ export default {
233237
},
234238
235239
// Server-side only
236-
ssrPrefetch () {
240+
serverPrefetch () {
237241
this.registerFoo()
238242
return this.fooInc()
239243
},
@@ -243,7 +247,7 @@ export default {
243247
// We already incremented 'count' on the server
244248
// We know by checking if the 'foo' state already exists
245249
const alreadyIncremented = !!this.$store.state.foo
246-
250+
247251
// We register the foo module
248252
this.registerFoo()
249253

0 commit comments

Comments
 (0)