diff --git a/README.md b/README.md index 327d2778..fdb6743e 100644 --- a/README.md +++ b/README.md @@ -1,33 +1,32 @@ -# vue-ssr-docs +# Pour traduire la documentation de vue-ssr-docs -Comprehensive guide for SSR (Server-Side Rendering) in Vue.js. Live at [ssr.vuejs.org](https://ssr.vuejs.org). +### Workflow de travail -## Development +Cette branche de travail `working` est volontairement mise en avant et doit uniquement être mise à jour dans le sens : -This site is powered by [VuePress](https://vuepress.vuejs.org/). +`vuejs/vue-ssr-docs:master` --> `vuejs-fr/vue-ssr-docs:working`. -``` bash -yarn -yarn dev +Nous traduisons les fichiers directement dans le dossier `en` sans les renommer. Cela permet lors de la mise à jour de la documentation via l'utilisation des commandes : + +``` +git fetch upstream +git working merge upstream/master ``` -## Contribute +d'obtenir des conflits **sur les pages déjà traduites** et ainsi maintenir la documentation à jour en fonction des modifications à travers **les documents déjà traduits**. + +Note : `git remote add upstream https://github.com/vuejs/vue-ssr-docs.git` est nécessaire au préalable pour utiliser les commandes ci-dessus. + +### Traduction -[gl]: https://gitlocalize.com -[gl-help]: https://docs.gitlocalize.com/ -[gl-issue-tracker]: https://github.com/gitlocalize/feedback -[gl-repo]: https://gitlocalize.com/repo/101 +Pour savoir ce qui est [en cours de traduction](https://github.com/vuejs-fr/vue-ssr-docs/issues/2) ou [comment traduire un fichier](https://github.com/vuejs-fr/vue-ssr-docs/issues/3), référez vous aux issues correspondantes. -### Translation +### Reverssement -We are useing with a translation tool called [GitLocalize][gl] and follow the steps to get started with your contribution: +Quand un fichier traduit est validé par pull request, on le met à jour dans le dossier `fr` de `vuejs-fr/vue-ssr-docs:master` puis on propose une pull request au site principal : -1. Go to [GitLocalize's vuejs/vue-ssr-docs repository][gl-repo]. -1. Sign up using your GitHub account :octocat:. -1. Find the document you are going to translate. -1. Happy translating :sparkles: . -1. When you are done, send the translation for reviews. -1. Reviewed translation will be sent as a Pull Request to GitHub by language admin in the community. +`vuejs-fr/vue-ssr-docs:master` --> `vuejs/vue-ssr-docs:master` -To learn more about how GitLocalize works, visit their [help page][gl-help]. If you find any issues or feature requests, please file them in [GitLocalize's issue tracker][gl-issue-tracker]. +ainsi le dossier officiel hébergeant la documentation possède bien le dossier `fr` en français et le dossier `en` en anglais. +Note : il peut être intéressant de faire une pull request par ficher validé et donc de créer une branche dérivée de `vuejs-fr/vue-ssr-docs:master` pour faire la pull request (`vuejs-fr/vue-ssr-docs:master` --> `vuejs-fr/vue-ssr-docs:only_one_changed_file_from_master` --> `vuejs/vue-ssr-docs:master`) diff --git a/docs/README.md b/docs/README.md index 01d42aab..505d7daa 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,53 +1,53 @@ -# Vue.js Server-Side Rendering Guide +# Guide du rendu côté serveur avec Vue.js ::: tip NOTE -This guide requires the following minimum versions of Vue and supporting libraries: +Ce guide nécessite les versions de Vue et de ses bibliothèques de support suivantes : - 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](./guide/structure.md) (with the new [runInNewContext](./api/#runinnewcontext) option set to `false`). Your existing app should continue to work, but it's recommended to migrate to the new recommendations. +Si vous avez déjà utilisé le rendu côté serveur (SSR pour *Server-Side Rendering*) avec Vue 2.2, vous vous apercevrez que la structure de code recommandée est maintenant [légèrement différente](./guide/structure.md) (avec la nouvelle option [runInNewContext](./api/#runinnewcontext) mise à `false`). Votre application devrait continuer à fonctionner, mais il est recommandé de migrer vers les nouvelles recommandations. ::: -## What is Server-Side Rendering (SSR)? +## Le rendu côté serveur ou SSR, qu'est-ce que c'est ? -Vue.js is a framework for building client-side applications. By default, Vue components produce and manipulate DOM in the browser as output. However, it is also possible to render the same components into HTML strings on the server, send them directly to the browser, and finally "hydrate" the static markup into a fully interactive app on the client. +Vue.js est un framework pour créer des applications côté client. Par défaut, Vue génère en sortie un DOM manipulable dans le navigateur. Il est cependant également possible de faire le rendu des mêmes composants sous forme de chaine de caractères HTML côté serveur, de les envoyer directement au navigateur et d'« hydrater » les balises statiques fournies en une application cliente pleinement interactive. -A server-rendered Vue.js app can also be considered "isomorphic" or "universal", in the sense that the majority of your app's code runs on both the server **and** the client. +Une application Vue.js rendue du côté serveur peut également être considérée comme « isomorphique » ou « universelle », dans le sens où la majorité du code est exécutable côté serveur **et** côté client. -## Why SSR? +## Pourquoi faire du SSR ? -Compared to a traditional SPA (Single-Page Application), the advantage of SSR primarily lies in: +En comparaison des applications monopages traditionnelles (SPA pour *Single-Page Application*), l'avantage du SSR se manifeste dans : -- Better SEO, as the search engine crawlers will directly see the fully rendered page. +- De meilleures optimisations pour les moteurs de recherche (SEO pour *Search Engine Optimisations*), ainsi les moteurs d'indexation voient directement le rendu complet de la page. - Note that as of now, Google and Bing can index synchronous JavaScript applications just fine. Synchronous being the key word there. If your app starts with a loading spinner, then fetches content via Ajax, the crawler will not wait for you to finish. This means if you have content fetched asynchronously on pages where SEO is important, SSR might be necessary. + À noter qu'à présent, Google et Bing savent parfaitement indexer des applications JavaScript synchrones. Synchrone est le mot important ici. Si votre application débute avec une animation de chargement, puis va chercher le contenu via Ajax, l'indexeur n'attendra pas que cette action soit finie. Cela signifie que si vous avez du contenu asynchrone injecté sur des pages où la SEO est importante, du SSR serait nécessaire. -- Faster time-to-content, especially on slow internet or slow devices. Server-rendered markup doesn't need to wait until all JavaScript has been downloaded and executed to be displayed, so your user will see a fully-rendered page sooner. This generally results in better user experience, and can be critical for applications where time-to-content is directly associated with conversion rate. +- De meilleurs temps d'accès au contenu, en particulier pour les connexions Internet lentes ou les appareils lents. Le rendu des balises côté serveur n'a pas besoin d'attendre le chargement de tous les fichiers JavaScript pour que le code soit exécuté en vue d'être affiché. Ainsi votre utilisateur verra apparaitre une page complètement rendue très tôt. Cela conduit généralement à une meilleure expérience utilisateur, ce qui peut-être critique pour les applications où le temps d'accès au contenu est directement lié au taux de conversion. -There are also some trade-offs to consider when using SSR: +Il y a aussi des contraintes à prendre en considération quand on utilise du SSR : -- Development constraints. Browser-specific code can only be used inside certain lifecycle hooks; some external libraries may need special treatment to be able to run in a server-rendered app. +- Des contraintes de développement. Le code spécifique aux navigateurs ne peut être utilisé que dans certains hooks ; plusieurs bibliothèques nécessitent une utilisation particulière pour être capables d'être exécutées dans une application côté serveur. -- More involved build setup and deployment requirements. Unlike a fully static SPA that can be deployed on any static file server, a server-rendered app requires an environment where a Node.js server can run. +- Plus d'étapes de précompilation et de déploiement requises. Contrairement à une SPA qui peut être déployée sur un serveur de fichiers statiques, une application rendue côté serveur nécessite un environnement où un serveur Node.js peut tourner. -- More server-side load. Rendering a full app in Node.js is obviously going to be more CPU-intensive than just serving static files, so if you expect high traffic, be prepared for corresponding server load and wisely employ caching strategies. +- Plus de charge côté serveur. Faire le rendu d'une application complète en Node.js est évidemment une tâche demandant plus de ressources CPU que de simplement renvoyer des fichiers statiques. Aussi si vous vous attendez à un fort trafic, préparez-vous un serveur tenant la charge et utilisez astucieusement des stratégies de mise en cache. -Before using SSR for your app, the first question you should ask is whether you actually need it. It mostly depends on how important time-to-content is for your app. For example, if you are building an internal dashboard where an extra few hundred milliseconds on initial load doesn't matter that much, SSR would be an overkill. However, in cases where time-to-content is absolutely critical, SSR can help you achieve the best possible initial load performance. +Avant d'utiliser du SSR pour vos applications, la première question que vous devriez vous poser est si vous en avez réellement besoin. Cela dépendra de l'importance du temps d'accès au contenu pour votre application. Par exemple, si vous créez une interface d'administration avec un chargement initial de quelques secondes, cela n'a pas d'importance ; du SSR n'aurait pas de pertinence dans ce cas. Cependant, dans le cas où l'accès au contenu est une priorité absolue, du SSR peut vous aider à obtenir les meilleures performances de chargement initial. -## SSR vs Prerendering +## Rendu côté serveur vs. pré-rendu -If you're only investigating SSR to improve the SEO of a handful of marketing pages (e.g. `/`, `/about`, `/contact`, etc), then you probably want __prerendering__ instead. Rather than using a web server to compile HTML on-the-fly, prerendering simply generates static HTML files for specific routes at build time. The advantage is setting up prerendering is much simpler and allows you to keep your frontend as a fully static site. +Si vous envisagez d'utiliser du SSR seulement pour améliorer votre SEO sur des pages informatives à valeur ajoutée (par ex. `/`, `/about`, `/contact`, etc.), alors vous devriez plutôt utiliser du pré-rendu. Plutôt que d'utiliser un serveur web pour compiler le HTML en temps réel, faites le simple pré-rendu de vos pages statiques en HTML pour des routes bien spécifiques lors d'une phase de précompilation. L'avantage est que faire du pré-rendu est plus simple et vous permet de garder un site avec une partie cliente statique. -If you're using webpack, you can easily add prerendering with the [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). It's been extensively tested with Vue apps - and in fact, [the creator](https://github.com/chrisvfritz) is a member of the Vue core team. +Si vous utilisez webpack, vous pouvez facilement ajouter du pré-rendu avec le plugin [prerender-spa-plugin](https://github.com/chrisvfritz/prerender-spa-plugin). Il a particulièrement bien été testé avec des applications Vue (en fait, [son créateur](https://github.com/chrisvfritz) est lui-même un membre de l'équipe principale de Vue). -## About This Guide +## À propos de ce guide -This guide is focused on server-rendered Single-Page Applications using Node.js as the server. Mixing Vue SSR with other backend setups is a topic of its own and briefly discussed in a [dedicated section](./guide/non-node.md). +Ce guide est dédié au rendu côté serveur des applications monopages utilisant Node.js en tant que serveur web. Utiliser le SSR de Vue avec une autre configuration serveur est un sujet brièvement abordé dans une [section dédiée](./guide/non-node.md). -This guide will be very in-depth and assumes you are already familiar with Vue.js itself, and have decent working knowledge of Node.js and webpack. If you prefer a higher-level solution that provides a smooth out-of-the-box experience, you should probably give [Nuxt.js](https://nuxtjs.org/) a try. It's built upon the same Vue stack but abstracts away a lot of the boilerplate, and provides some extra features such as static site generation. However, it may not suit your use case if you need more direct control of your app's structure. Regardless, it would still be beneficial to read through this guide to better understand how things work together. +Ce guide va réellement entrer dans le détail et présuppose que vous êtes déjà familiarisé avec Vue.js et que vous avez un niveau de connaissance correcte concernant Node.js et webpack. Si vous préférez une solution de haut niveau fournissant une expérience de développement prête à l'emploi, vous devriez probablement essayer [Nuxt.js](https://nuxtjs.org/). Il est construit par-dessus l'écosystème de Vue et vous fournit des éléments préconçus ainsi que des fonctionnalités supplémentaires pour générer des sites web statiques. Il ne vous conviendra cependant pas si vous souhaitez avoir un contrôle plus direct sur la structure de votre application. Dans tous les cas, il reste toujours intéressant de parcourir ce guide pour mieux comprendre comment chaque élément fonctionne avec le reste. -As you read along, it would be helpful to refer to the official [HackerNews Demo](https://github.com/vuejs/vue-hackernews-2.0/), which makes use of most of the techniques covered in this guide. +Au fil de votre lecture, il peut être intéressant également de vous référer à la [démo HackerNews](https://github.com/vuejs/vue-hackernews-2.0/) qui utilise bon nombre des techniques expliquées dans ce guide. -Finally, note that the solutions in this guide are not definitive - we've found them to be working well for us, but that doesn't mean they cannot be improved. They might get revised in the future - and feel free to contribute by submitting pull requests! +Pour finir, notez que les solutions de ce guide ne sont pas définitives. Nous avons trouvé que cela fonctionnait bien pour nous, mais cela ne veut pas dire qu'il n'y a pas d'améliorations à faire. Nous pourrons les réviser dans le futur. N'hésitez donc pas à y contribuer en soumettant des pull requests ! diff --git a/docs/guide/README.md b/docs/guide/README.md index 15485e25..97d3aae5 100644 --- a/docs/guide/README.md +++ b/docs/guide/README.md @@ -1,4 +1,4 @@ -# Getting Started +# Pour commencer ## Installation @@ -6,34 +6,34 @@ npm install vue vue-server-renderer --save ``` -We will be using NPM throughout the guide, but feel free to use [Yarn](https://yarnpkg.com/en/) instead. +Nous allons utiliser npm tout au long de ce guide, n'hésitez pas à utiliser [Yarn](https://yarnpkg.com/en/) à la place. #### Notes -- It's recommended to use Node.js version 6+. -- `vue-server-renderer` and `vue` must have matching versions. -- `vue-server-renderer` relies on some Node.js native modules and therefore can only be used in Node.js. We may provide a simpler build that can be run in other JavaScript runtimes in the future. +- Il est recommandé d'utiliser une version 6 ou supérieur de Node.js +- `vue-server-renderer` et `vue` doivent utiliser des numéros de version identiques. +- `vue-server-renderer` utilise plusieurs modules Node.js natifs fournis uniquement par Node.js. Nous fournirons une version exécutable qui pourra tourner sur les autres moteurs JavaScript dans le futur. -## Rendering a Vue Instance +## Faire le rendu d'une instance de Vue ``` js -// Step 1: Create a Vue instance +// Étape 1 : créer une instance de Vue const Vue = require('vue') const app = new Vue({ template: `
Hello World
` }) -// Step 2: Create a renderer +// Étape 2 : créer un moteur de rendu const renderer = require('vue-server-renderer').createRenderer() -// Step 3: Render the Vue instance to HTML +// Étape 3 : faire le rendu de l'instance en HTML renderer.renderToString(app, (err, html) => { if (err) throw err console.log(html) // =>
Hello World
}) -// in 2.5.0+, returns a Promise if no callback is passed: +// Dans la 2.5.0+, retourne une promesse si aucune fonction de rappel n'est passée : renderer.renderToString(app).then(html => { console.log(html) }).catch(err => { @@ -41,9 +41,9 @@ renderer.renderToString(app).then(html => { }) ``` -## Integrating with a Server +## Intégration avec un serveur -It is pretty straightforward when used inside a Node.js server, for example [Express](https://expressjs.com/): +Il est plus simple d'utiliser le code précédent avec un serveur Node.js, par exemple [Express](https://expressjs.com/) : ``` bash npm install express --save @@ -59,18 +59,18 @@ server.get('*', (req, res) => { data: { url: req.url }, - template: `
The visited URL is: {{ url }}
` + template: `
L'URL visité est : {{ url }}
` }) renderer.renderToString(app, (err, html) => { if (err) { - res.status(500).end('Internal Server Error') + res.status(500).end('Erreur interne du serveur') return } res.end(` - Hello + Bonjour ${html} `) @@ -80,25 +80,25 @@ server.get('*', (req, res) => { server.listen(8080) ``` -## Using a Page Template +## Utiliser un modèle de page -When you render a Vue app, the renderer only generates the markup of the app. In the example we had to wrap the output with an extra HTML page shell. +Quand vous faites le rendu d'une application Vue, le moteur de rendu fournit uniquement les balises de votre application. Dans cet exemple, nous allons ajouter de part et d'autre la structure HTML nécessaire à toutes pages. -To simplify this, you can directly provide a page template when creating the renderer. Most of the time we will put the page template in its own file, e.g. `index.template.html`: +Le plus simple est de directement fournir un modèle de page lors de la création du moteur de rendu. La plupart du temps, nous allons mettre le modèle de page dans son propre fichier. Par ex. `index.template.html` : ``` html - Hello + Bonjour ``` -Notice the `` comment -- this is where your app's markup will be injected. +Notez que le commentaire `` représente la zone où les balises de votre application vont être injectées. -We can then read and pass the file to the Vue renderer: +Nous allons ensuite lire et passer le contenu du fichier au générateur de rendu de Vue : ``` js const renderer = createRenderer({ @@ -106,21 +106,21 @@ const renderer = createRenderer({ }) renderer.renderToString(app, (err, html) => { - console.log(html) // will be the full page with app content injected. + console.log(html) // sera la page complète avec le contenu de l'application injecté. }) ``` -### Template Interpolation +### Interpolation dans le modèle de page -The template also supports simple interpolation. Given the following template: +Le modèle de page supporte également une interpolation simple. Avec le modèle de page suivant : ``` html - + {{ title }} - + {{{ meta }}} @@ -129,11 +129,11 @@ The template also supports simple interpolation. Given the following template: ``` -We can provide interpolation data by passing a "render context object" as the second argument to `renderToString`: +Nous pouvons fournir les données d'interpolation suivantes à travers un « objet de contexte de rendu » en tant que second argument de `renderToString` : ``` js const context = { - title: 'hello', + title: 'Bonjour', meta: ` @@ -141,17 +141,17 @@ const context = { } renderer.renderToString(app, context, (err, html) => { - // page title will be "Hello" - // with meta tags injected + // le titre de la page sera « Bonjour » + // avec les balises `` injectées }) ``` -The `context` object can also be shared with the Vue app instance, allowing components to dynamically register data for template interpolation. +L'objet `context` peut également être partagé avec l'instance de l'application de Vue, permettant aux composants de dynamiquement fournir des données pour l'interpolation du modèle de page. -In addition, the template supports some advanced features such as: +De plus, le modèle de page supporte des fonctionnalités avancées comme : -- Auto injection of critical CSS when using `*.vue` components; -- Auto injection of asset links and resource hints when using `clientManifest`; -- Auto injection and XSS prevention when embedding Vuex state for client-side hydration. +- l'injection automatique de CSS critique lors de l'utilisation de composants `*.vue`, +- l'injection automatique de balises `` avec l'utilisation de `clientManifest`, +- l'injection automatique de l'état de Vuex pour l'hydratation cliente avec prévention XSS. -We will discuss these when we introduce the associated concepts later in the guide. +Nous discuterons de cela quand nous introduirons ces concepts plus tard dans le guide. diff --git a/docs/guide/build-config.md b/docs/guide/build-config.md index f40ed423..b964df3b 100644 --- a/docs/guide/build-config.md +++ b/docs/guide/build-config.md @@ -1,10 +1,10 @@ -# Build Configuration +# Configuration de précompilation -We will assume you already know how to configure webpack for a client-only project. The config for an SSR project will be largely similar, but we suggest breaking the config into three files: *base*, *client* and *server*. The base config contains config shared for both environments, such as output path, aliases, and loaders. The server config and client config can simply extend the base config using [webpack-merge](https://github.com/survivejs/webpack-merge). +Nous allons supposez que vous savez déjà comment configurer webpack pour un projet uniquement client. La configuration pour un projet avec du SSR va être en grande partie similaire, mais nous vous suggérons de séparer vos configurations en trois fichiers : *base*, *client* et *server*. La configuration de base contient la configuration partagée par les deux environnements, comme les chemins de sortie, les aliases et les loaders. La configuration du serveur et la configuration du client peuvent simplement étendre la configuration de base en utilisant [webpack-merge](https://github.com/survivejs/webpack-merge). -## Server Config +## Configuration serveur -The server config is meant for generating the server bundle that will be passed to `createBundleRenderer`. It should look like this: +La configuration serveur est destinée à générer le paquetage serveur qui va être passé à `createBundleRenderer`. Elle devrait ressembler à cela : ``` js const merge = require('webpack-merge') @@ -13,35 +13,35 @@ const baseConfig = require('./webpack.base.config.js') const VueSSRServerPlugin = require('vue-server-renderer/server-plugin') module.exports = merge(baseConfig, { - // Point entry to your app's server entry file + // Fichier d'entrée serveur de l'application entry: '/path/to/entry-server.js', - // This allows webpack to handle dynamic imports in a Node-appropriate - // fashion, and also tells `vue-loader` to emit server-oriented code when - // compiling Vue components. + // Cela permet à webpack de gérer les imports dynamiques d'une manière + // approprié pour Node.js, et dit également à `vue-loader` d'émettre un code approprié pour le serveur + // lors de la compilation du composant Vue. target: 'node', - // For bundle renderer source map support + // Pour le support des sources maps des paquetages devtool: 'source-map', - // This tells the server bundle to use Node-style exports + // Cela dit au paquetage serveur d'utiliser les exports au format Node.js output: { libraryTarget: 'commonjs2' }, // https://webpack.js.org/configuration/externals/#function // https://github.com/liady/webpack-node-externals - // Externalize app dependencies. This makes the server build much faster - // and generates a smaller bundle file. + // Externalise les dépendances de l'application. Cela rend le build serveur plus rapide + // et génère un fichier de paquetage plus petit. externals: nodeExternals({ - // do not externalize dependencies that need to be processed by webpack. - // you can add more file types here e.g. raw *.vue files - // you should also whitelist deps that modifies `global` (e.g. polyfills) + // ne pas externaliser les dépendances qui ont besoin d'être traitées par webpack. + // vous pouvez ajouter plus de types de fichiers ici, comme par ex. avec les fichiers `*.vue` + // vous devriez aussi lister des exceptions qui modifient `global` (par ex. les polyfills) whitelist: /\.css$/ }), - // This is the plugin that turns the entire output of the server build - // into a single JSON file. The default file name will be + // Ceci est le plugin qui va créer entièrement la sortie pour le build serveur + // dans un seul fichier JSON. Le fichier généré par défaut va être // `vue-ssr-server-bundle.json` plugins: [ new VueSSRServerPlugin() @@ -49,40 +49,40 @@ module.exports = merge(baseConfig, { }) ``` -After `vue-ssr-server-bundle.json` has been generated, simply pass the file path to `createBundleRenderer`: +Après que `vue-ssr-server-bundle.json` ai été généré, passez simplement le chemin du fichier à `createBundleRenderer` : ``` js const { createBundleRenderer } = require('vue-server-renderer') const renderer = createBundleRenderer('/path/to/vue-ssr-server-bundle.json', { - // ...other renderer options + // ...autres options pour le moteur }) ``` -Alternatively, you can also pass the bundle as an Object to `createBundleRenderer`. This is useful for hot-reload during development - see the HackerNews demo for a [reference setup](https://github.com/vuejs/vue-hackernews-2.0/blob/master/build/setup-dev-server.js). +Vous pouvez alternativement tout aussi bien passer le paquetage comme un objet à `createBundleRenderer`. Cela est utile pour le rechargement à chaud pendant le développement. Voyez la démo de HackerNews pour une [référence de mise en place](https://github.com/vuejs/vue-hackernews-2.0/blob/master/build/setup-dev-server.js). -### Externals Caveats +### Limitations externes -Notice that in the `externals` option we are whitelisting CSS files. This is because CSS imported from dependencies should still be handled by webpack. If you are importing any other types of files that also rely on webpack (e.g. `*.vue`, `*.sass`), you should add them to the whitelist as well. +Notons que dans l'option `externals` nous avons exclu les fichiers CSS. C'est parce que les fichiers CSS importés par dépendances doivent quand même être gérés par webpack. Si vous importez n'importe quels autres types de fichiers également pris en charge par webpack (ex : `*.vue`, `*.styl`), vous pouvez également les ajouter à la liste des exceptions. -If you are using `runInNewContext: 'once'` or `runInNewContext: true`, then you also need to whitelist polyfills that modify `global`, e.g. `babel-polyfill`. This is because when using the new context mode, **code inside a server bundle has its own `global` object.** Since you don't really need it on the server when using Node 7.6+, it's actually easier to just import it in the client entry. +Si vous utilisez `runInNewContext: 'once'` ou `runInNewContext: true`, alors vous devrez également ajouter aux exceptions les polyfills qui modifient `global` comme par ex. `babel-polyfill`. Cela est dû au fait qu'en utilisant un nouveau mode de contexte, **le code à l'intérieur d'un paquetage serveur a son propre objet `global`.** Parce qu'il n'est plus nécessaire de faire cela côté serveur en utilisant Node.js 7.6+, c'est d'autant plus facile de ne les importer que côté client. -## Client Config +## Configuration cliente -The client config can remain largely the same with the base config. Obviously you need to point `entry` to your client entry file. Aside from that, if you are using `CommonsChunkPlugin`, make sure to use it only in the client config because the server bundle requires a single entry chunk. +La configuration cliente peut être en grande partie la même grâce à la configuration de base. Bien sûr vous devez faire pointer `entry` sur votre fichier d'entrée client. En plus de cela, si vous utilisez le plugin `CommonsChunkPlugin`, assurez-vous de ne l'utiliser que dans la configuration cliente car le paquetage serveur requiert un unique fragment d'entrée. -### Generating `clientManifest` +### Générer le `clientManifest` -> requires version 2.3.0+ +> requiert la version 2.3.0+ -In addition to the server bundle, we can also generate a client build manifest. With the client manifest and the server bundle, the renderer now has information of both the server *and* client builds, so it can automatically infer and inject [preload / prefetch directives](https://css-tricks.com/prefetching-preloading-prebrowsing/) and css links / script tags into the rendered HTML. +En plus du paquetage serveur, nous pouvons également générer un build de manifeste client. Avec le manifeste client et le paquetage serveur, le moteur a maintenant les informations du build serveur *et* du build client, ainsi il peut automatiquement déduire et injecter les [directives préchargées et récupérées](https://css-tricks.com/prefetching-preloading-prebrowsing/) ainsi que les balises `` / ` - + ` ``` -### Manual Asset Injection +### Injection manuelle des fichiers -By default, asset injection is automatic when you provide the `template` render option. But sometimes you might want finer-grained control over how assets are injected into the template, or maybe you are not using a template at all. In such a case, you can pass `inject: false` when creating the renderer and manually perform asset injection. +Par défaut, l'injection des fichiers est automatique quand vous fournissez l'option de rendu `template`. Mais parfois vous aurez besoin d'une granularité de contrôle plus fine en ce qui concerne la manière dont les templates seront injectés, ou peut-être que vous n'utiliserez pas de template du tout. Dans tous les cas, vous pouvez passer `inject: false` quand le moteur est créé et manuellement réaliser l'injection des fichiers. -In the `renderToString` callback, the `context` object you passed in will expose the following methods: +Dans la fonction de rappel de `renderToString`, l'objet `context` que vous passez va exposer les méthodes suivantes : - `context.renderStyles()` - This will return inline `