Merge branch 'api' of https://github.com/vuejs-fr/vue-ssr-docs into api

Author: MachinisteWeb

Diff for: en/SUMMARY.md

@@ -8,8 +8,8 @@
 - [Configuration de pré-compilation](build-config.md)
 - [Gestion des CSS](css.md)
 - [Gestion des entêtes (En)](head.md)
-- [Mise en cache (En)](caching.md)
-- [Envoi par flux (En)](streaming.md)
+- [Mise en cache](caching.md)
+- [Envoi par flux](streaming.md)
 - [Référence de l'API](api.md)
   - [createRenderer](api.md#createrendereroptions)
   - [createBundleRenderer](api.md#createbundlerendererbundle-options)

Diff for: en/caching.md

@@ -1,22 +1,22 @@
-# Mise en cache (En) <br><br> *Cette page est en cours de traduction française. Revenez une autre fois pour lire une traduction achevée ou [participez à la traduction française ici](https://github.com/vuejs-fr/vue-ssr-docs).*
+# Mise en cache
 
-Although Vue's SSR is quite fast, it can't match the performance of pure string-based templating due to the cost of creating component instances and Virtual DOM nodes. In cases where SSR performance is critical, wisely leveraging caching strategies can greatly improve response time and reduce server load.
+Même si le SSR de Vue est très rapide, il ne peut égaler les performances d'un rendu utilisant une chaîne de caractères pure du fait du coût de la création des instances de composants et des nœuds du DOM virtuel. Dans le cas ou les performances du SSR seraient critiques, il est conseillé d'utiliser une stratégie de mise en cache pour améliorer significativement le temps de réponse et réduire la charge du serveur.
 
-## Page-level Caching
+## Mise en cache au niveau de la page
 
-A server-rendered app in most cases relies on external data, so the content is dynamic by nature and cannot be cached for extended periods. However, if the content is not user-specific (i.e. for the same URL it always renders the same content for all users), we can leverage a strategy called [micro-caching](https://www.nginx.com/blog/benefits-of-microcaching-nginx/) to drastically improve our app's capability of handling high traffic.
+Une application de rendu côté serveur est, dans la plupart des cas, liée à des données externes. Donc le contenu est dynamique par nature et ne peut pas être mis en cache pour des périodes étendues. Cependant, si le contenu n'est pas spécifique à un utilisateur (c.-à-d. qu'un même URL rend toujours un même contenu indépendamment des utilisateurs), nous pouvons mettre en place une stratégie appelée [micro-caching](https://www.nginx.com/blog/benefits-of-microcaching-nginx/) pour améliorer significativement la capacité de notre application à prendre en charge un fort trafique.
 
-This is usually done at the Nginx layer, but we can also implement it in Node.js:
+Ceci est habituellement fait au niveau de la couche nginx, mais nous pouvons également l'implémenter en Node.js :
 
 ``` js
 const microCache = LRU({
   max: 100,
-  maxAge: 1000 // Important: entries expires after 1 second.
+  maxAge: 1000 // Important : les entrées expires après une seconde.
 })
 
 const isCacheable = req => {
-  // implement logic to check if the request is user-specific.
-  // only non-user-specific pages are cache-able
+  // implémentation d'un algorithme pour définir si une requête est spécifique à un utilisateur.
+  // seules les pages non spécifiques à un utilisateur peuvent être mises en cache
 }
 
 server.get('*', (req, res) => {
@@ -37,11 +37,11 @@ server.get('*', (req, res) => {
 })
 ```
 
-Since the content is cached for only one second, users will not see outdated content. However, this means the server only has to perform at most one full render per second for each cached page.
+Parce que le composant est mis en cache pour seulement une seconde, les utilisateurs ne verront pas le contenu déjà périmé. Cependant, cela signifie que le serveur a besoin de faire un rendu complet une seule fois par seconde pour chaque page mise en cache.
 
-## Component-level Caching
+## Mise en cache au niveau du composant
 
-`vue-server-renderer` has built-in support for component-level caching. To enable it you need to provide a [cache implementation](./api.md#cache) when creating the renderer. Typical usage is passing in an [lru-cache](https://github.com/isaacs/node-lru-cache):
+`vue-server-renderer` a un support intégré pour la mise en cache de composant. Pour l'activer, vous avez besoin d'une [implémentation de mise en cache](./api.md#cache) quand vous créez le moteur de rendu. L'usage courant est de passer un [objet de mise en cache qui supprime l'objet le plus récemment utilisé](https://github.com/isaacs/node-lru-cache) :
 
 ``` js
 const LRU = require('lru-cache')
@@ -54,11 +54,11 @@ const renderer = createRenderer({
 })
 ```
 
-You can then cache a component by implementing a `serverCacheKey` function:
+Vous pouvez aussi implémenter une mise en cache de composant avec une fonction `serverCacheKey` :
 
 ``` js
 export default {
-  name: 'item', // required
+  name: 'item', // requis
   props: ['item'],
   serverCacheKey: props => props.item.id,
   render (h) {
@@ -67,20 +67,20 @@ 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.
+Notez que ce composant pouvant être mis en cache **doit aussi définir une option `name` unique**. Avec un nom unique, la clé de mise en cache est effective par composant : vous n'avez donc pas besoin de vous préoccuper de deux composants qui retourneraient la même clé.
 
-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.
+La clé retournée par `serverCacheKey` devrait contenir suffisamment d'informations pour représenter tous les résultats de rendu. L'exemple ci-dessus est une bonne implémentation si le résultat du rendu est uniquement déterminé par `props.item.id`. Cependant, si un élément avec le même identifiant change à chaque fois, ou si son rendu est lié au changement d'une autre prop, alors vous devez modifier votre implémentation `getCacheKey` pour prendre en compte ces variables.
 
-Returning a constant will cause the component to always be cached, which is good for purely static components.
+Retourner une constante va mener le composant à toujours être en cache, ce qui peut être une bonne chose pour les composants statiques.
 
-### When to use component caching
+### Quand utiliser de la mise en cache de composant ?
 
-If the renderer hits a cache for a component during render, it will directly reuse the cached result for the entire sub tree. This means you should **NOT** cache a component when:
+Si le moteur de rendu trouve du cache pour un composant durant le rendu, il va directement utiliser ce cache comme résultat pour le sous arbre de composant complet. Cela signifie qu'il ne faut **PAS** mettre en cache un composant quand :
 
-- It has child components that may rely on global state.
-- It has child components that produces side effects on the render `context`.
+- Il possède des composants enfants liés à l'état global.
+- Il possède des composants enfants qui produisent des effets de bord sur le rendu de `context`.
 
-Component caching should therefore be applied carefully to address performance bottlenecks. In most cases, you shouldn't and don't need to cache single-instance components. The most common type of components that are suitable for caching are ones repeated in big `v-for` lists. Since these components are usually driven by objects in database collections, they can make use of a simple caching strategy: generate their cache keys using their unique id plus the last updated timestamp:
+La mise en cache de composant doit donc être utilisée avec soin pour éviter les goulots d'étranglement de performance. Dans la plupart des cas, vous n'en aurez pas besoin et donc pas besoin de mettre en cache les instances de composants. Les types de composants les plus communs pour de la mise en cache sont ceux utilisant de grosses listes `v-for`. Comme ces composants sont généralement alimentés par des collections de base de données, ils peuvent utiliser une simple stratégie de mise en cache : générer leur clé de mise en cache en utilisant leur unique identifiant associé à un timestamp mis à jour :
 
 ``` js
 serverCacheKey: props => props.item.id + '::' + props.item.last_updated

Diff for: en/head.md

@@ -1,17 +1,17 @@
-# Gestion des entêtes (En) <br><br> *Cette page est en cours de traduction française. Revenez une autre fois pour lire une traduction achevée ou [participez à la traduction française ici](https://github.com/vuejs-fr/vue-ssr-docs).*
+# Gestion des entêtes
 
-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`.
+Similaire à l'injection de fichier, la gestion des entêtes suit la même idée : nous pouvons dynamiquement attacher des données au rendu `context` dans le cycle de vie du composant, et interpoler ses données dans le 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`.
+> Dans la version 2.3.2+, vous pouvez directement accéder au contexte SSR du composant via `this.$ssrContext`. Dans les versions plus anciennes, vous devez injecter manuellement le contexte SSR en le passant à la fonction `createApp()` et ainsi l'exposer dans `$options` de l'instance racine — les composants enfants pouvant y accéder via `this.$root.$options.ssrContext`.
 
-We can write a simple mixin to perform title management:
+Nous pouvons écrire un mixin simple pour effectuer la gestion du titre :
 
 ``` js
 // title-mixin.js
 
 function getTitle (vm) {
-  // components can simply provide a `title` option
-  // which can be either a string or a function
+  // les composants doivent simplement fournir une option `title`
+  // pouvant être soit une chaîne de caractères soit une fonction
   const { title } = vm.$options
   if (title) {
     return typeof title === 'function'
@@ -38,13 +38,13 @@ const clientTitleMixin = {
   }
 }
 
-// VUE_ENV can be injected with webpack.DefinePlugin
+// `VUE_ENV` peut être injecté avec `webpack.DefinePlugin`
 export default process.env.VUE_ENV === 'server'
   ? serverTitleMixin
   : clientTitleMixin
 ```
 
-Now, a route component can make use of this to control the document title:
+Maintenant, un composant de route peut être utilisé ainsi pour contrôler le titre du document :
 
 ``` js
 // Item.vue
@@ -66,7 +66,7 @@ export default {
 }
 ```
 
-And inside the `template` passed to bundle renderer:
+Et passé au moteur de rendu de paquetage dans le template.
 
 ``` html
 <html>
@@ -79,12 +79,12 @@ And inside the `template` passed to bundle renderer:
 </html>
 ```
 
-**Notes:**
+**Notes :**
 
-- Use double-mustache (HTML-escaped interpolation) to avoid XSS attacks.
+- Utilisez les doubles moustaches (interpolation de HTML échapé) pour éviter les attaques XSS.
 
-- You should provide a default title when creating the `context` object in case no component has set a title during render.
+- Vous devriez fournir un titre par défaut quand vous créez l'object `context` au cas ou aucun composant de définisse de titre durant le rendu.
 
 ---
 
-Using the same strategy, you can easily expand this mixin into a generic head management utility.
+En utilisant la même stratégie, vous pouvez facilement étendre votre mixin en une fonction utilitaire générique de gestion des entêtes.

Diff for: en/streaming.md

@@ -1,12 +1,13 @@
-# Envoi par flux (En) <br><br> *Cette page est en cours de traduction française. Revenez une autre fois pour lire une traduction achevée ou [participez à la traduction française ici](https://github.com/vuejs-fr/vue-ssr-docs).*
+# Envoi par flux
 
-`vue-server-renderer` supports stream rendering out of the box, for both the base renderer and the bundle renderer. All you need to do is use `renderToStream` instead of `renderToString`:
+`vue-server-renderer` supporte nativement le rendu par flux (« stream »), aussi bien pour le moteur de rendu de base que pour le moteur de rendu de paquetage. Tout ce dont vous avez besoin est d'utiliser `renderToStream` à la place de `renderToString` :
+:
 
 ``` js
 const stream = renderer.renderToStream(context)
 ```
 
-The returned value is a [Node.js stream](https://nodejs.org/api/stream.html):
+La valeur retournée est un [flux Node.js](https://nodejs.org/api/stream.html) :
 
 ``` js
 let html = ''
@@ -24,10 +25,10 @@ stream.on('error', err => {
 })
 ```
 
-## Streaming Caveats
+## Limitations de flux
 
-In stream rendering mode, data is emitted as soon as possible when the renderer traverses the Virtual DOM tree. This means we can get an earlier "first chunk" and start sending it to the client faster.
+En mode de rendu par flux, la donnée est émise aussitôt que possible quand le moteur parcourt l'arbre du DOM virtuel. Cela signifie que l'envoi au client du « premier fragment » commence rapidement.
 
-However, when the first data chunk is emitted, the child components may not even be instantiated yet, neither will their lifecycle hooks get called. This means if the child components need to attach data to the render context in their lifecycle hooks, these data will not be available when the stream starts. Since a lot of the context information (like head information or inlined critical CSS) needs to be appear before the application markup, we essentially have to wait until the stream to complete before we can start making use of these context data.
+Cependant, quand le premier fragment est émis, les composants enfants peuvent ne pas avoir encore été instanciés, et les hooks de leur cycle de vie ne seront jamais appelés. Cela signifie que si des composants enfants ont besoin d'attacher leurs données dans le contexte de rendu de leurs hooks de cycle de vie, elles ne seront pas accessibles au démarrage du flux. Comme beaucoup d'informations (comme les informations d'entête ou les CSS critiques injectées) ont besoin d'être insérées avant la balise de l'application, il est nécessaire d'attendre la fin du flux avant de commencer à utiliser ces données de contexte.
 
-It is therefore **NOT** recommended to use streaming mode if you rely on context data populated by component lifecycle hooks.
+Il n'est donc **PAS** recommandé d'utiliser de l'envoi par flux si les données de vos contextes sont injectés dans les hooks du cycle de vie.