Skip to content

[Doc EN] — Several files — Consistency changes #106

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Aug 14, 2017
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions en/README.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
# Vue.js Server-Side Rendering Guide

> **Note:** this guide requires the following minimum versions of Vue and supporting libraries:
> - vue & vue-server-renderer >= 2.3.0
> - vue-router >= 2.5.0
> - vue-loader >= 12.0.0 & vue-style-loader >= 3.0.0
> - vue & vue-server-renderer 2.3.0+
> - vue-router 2.5.0+
> - vue-loader 12.0.0+ & vue-style-loader 3.0.0+
> If you have previously used Vue 2.2 with SSR, you will notice that the recommended code structure is now [a bit different](./structure.md) (with the new [runInNewContext](./api.md#runinnewcontext) option set to `false`). Your existing app should continue to work, but it's recommended to migrate to the new recommendations.
Expand Down
4 changes: 2 additions & 2 deletions en/api.md
Original file line number Diff line number Diff line change
Expand Up @@ -151,7 +151,7 @@ See [Introducing the Server Bundle](./bundle-renderer.md) and [Build Configurati
- 2.2.0+
- only used in `createBundleRenderer`

Explicitly declare the base directory for the server bundle to resolve `node_modules` dependencies from. This is only needed if your generated bundle file is placed in a different location from where the externalized NPM dependencies are installed, or your `vue-server-renderer` is npm-linked into your current project.
Explicitly declare the base directory for the server bundle to resolve `node_modules` dependencies from. This is only needed if your generated bundle file is placed in a different location from where the externalized NPM dependencies are installed, or your `vue-server-renderer` is NPM-linked into your current project.

- #### `cache`

Expand All @@ -177,7 +177,7 @@ See [Introducing the Server Bundle](./bundle-renderer.md) and [Build Configurati
})
```

Note that the cache object should at least implement `get` and `set`. In addition, `get` and `has` can be optionally async if they accept a second argument as callback. This allows the cache to make use of async APIs, e.g. a redis client:
Note that the cache object should at least implement `get` and `set`. In addition, `get` and `has` can be optionally async if they accept a second argument as callback. This allows the cache to make use of async APIs, e.g. a Redis client:

``` js
const renderer = createRenderer({
Expand Down
2 changes: 1 addition & 1 deletion en/caching.md
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,7 @@ export default {
}
```

Note that cache-able component **must also define a unique "name" option**. With a unique name, the cache key is thus per-component: you don't need to worry about two components returning the same key.
Note that cache-able component **must also define a unique `name` option**. With a unique name, the cache key is thus per-component: you don't need to worry about two components returning the same key.

The key returned from `serverCacheKey` should contain sufficient information to represent the shape of the render result. The above is a good implementation if the render result is solely determined by `props.item.id`. However, if the item with the same id may change over time, or if render result also relies on another prop, then you need to modify your `getCacheKey` implementation to take those other variables into account.

Expand Down
2 changes: 1 addition & 1 deletion en/css.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ More importantly, `vue-style-loader`, the loader used internally by `vue-loader`

## Enabling CSS Extraction

To extract CSS from `*.vue` files, use `vue-loader`'s `extractCSS` option (requires `vue-loader>=12.0.0`):
To extract CSS from `*.vue` files, use `vue-loader`'s `extractCSS` option (requires `vue-loader` 12.0.0+):

``` js
// webpack.config.js
Expand Down
6 changes: 3 additions & 3 deletions en/head.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@

Similar to asset injection, head management follows the same idea: we can dynamically attach data to the render `context` in a component's lifecycle, and then interpolate those data in `template`.

> In version >=2.3.2, you can directly access the SSR context in a component as `this.$ssrContext`. In older versions you'd have to manually inject the SSR context by passing it to `createApp()` and expose it on the root instance's `$options` - child components can then access it via `this.$root.$options.ssrContext`.
> In version 2.3.2+, you can directly access the SSR context in a component as `this.$ssrContext`. In older versions you'd have to manually inject the SSR context by passing it to `createApp()` and expose it on the root instance's `$options` - child components can then access it via `this.$root.$options.ssrContext`.
We can write a simple mixin to perform title management:

Expand Down Expand Up @@ -38,7 +38,7 @@ const clientTitleMixin = {
}
}

// VUE_ENV can be injected with webpack.DefinePlugin
// `VUE_ENV` can be injected with `webpack.DefinePlugin`
export default process.env.VUE_ENV === 'server'
? serverTitleMixin
: clientTitleMixin
Expand Down Expand Up @@ -66,7 +66,7 @@ export default {
}
```

And inside the `template` passed to bundle renderer:
And inside the template passed to bundle renderer:

``` html
<html>
Expand Down