Traduction de universal & structure

en/structure.md

@@ -1,12 +1,12 @@
-# Structure de code (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).*
+# Structure de code
 
-## Avoid Stateful Singletons
+## Eviter les singletons d'état
 
-When writing client-only code, we are used to the fact that our code will be evaluated in a fresh context every time. However, a Node.js server is a long-running process. When our code is required into the process, it will be evaluated once and stays in memory. This means if you create a singleton object, it will be shared between every incoming request.
+Lors de l'écriture du code exclusif au client, nous sommes habitués au fait que notre code sera interprété dans un nouveau contexte à chaque fois. Cependant, un serveur Node.js est un processus qui reste actif. Quand notre code est appelé dans le processus, il sera interprété une fois et restera en mémoire. Cela signifie que si vous créez un singleton, il sera partagé entre chaque nouvelle requête.
 
-As seen in the basic example, we are **creating a new root Vue instance for each request.** This is similar to how each user will be using a fresh instance of the app in their own browser. If we use a shared instance across multiple requests, it will easily lead to cross-request state pollution.
+Comme vu dans l'exemple de base, nous **créons une nouvelle instance de Vue principale pour chaque requête.** Cela est similaire au fait que chaque utilisateur utilise une nouvelle instance de l'application dans son propre navigateur. Si nous utilisons une instance partagée entre plusieurs requêtes, nous prenons le risque d'une pollution d'état entre requêtes.
 
-So, instead of directly creating an app instance, we should expose a factory function that can be repeatedly executed to create fresh app instances for each request:
+Ainsi, au lieu de créer directement une instance d'application, nous devons exposer une fonction de fabrique qui peut être exécutée à plusieurs reprises pour créer de nouvelles instances d'application pour chaque requête :
 
 ``` js
 // app.js
@@ -17,12 +17,12 @@ module.exports = function createApp (context) {
     data: {
       url: context.url
     },
-    template: `<div>The visited URL is: {{ url }}</div>`
+    template: `<div>L'URL visible est : {{ url }}</div>`
   })
 }
 ```
 
-And our server code now becomes:
+Et notre code serveur devient:
 
 ``` js
 // server.js
@@ -33,35 +33,35 @@ server.get('*', (req, res) => {
   const app = createApp(context)
 
   renderer.renderToString(app, (err, html) => {
-    // handle error...
+    // gérer l'erreur...
     res.end(html)
   })
 })
 ```
 
-The same rule applies to router, store and event bus instances as well. Instead of exporting it directly from a module and importing it across your app, you need to create a fresh instance in `createApp` and inject it from the root Vue instance.
+La même règle s'applique aussi bien au routeur, qu'au store et aux instances de bus d'événements. Au lieu de l'exporter directement depuis un module et de l'importer dans votre application, vous devez créer une nouvelle instance dans `createApp` et l'injecter depuis l'instance de Vue principale.
 
-> This constraint can be eliminated when using the bundle renderer with `{ runInNewContext: true }`, however it comes with some significant performance cost because a new vm context needs to be created for each request.
+> Cette contrainte peut être éliminée en utilisant le moteur de rendu pré-compilé ("bundle renderer") avec `{ runInNewContext: true }`, cependant il y aura un surcoût significatif en terme de performance lié à la création d'un nouveau contexte vm pour chaque requête.
 
-## Introducing a Build Step
+## Introduction à l'étape de build
 
-So far, we haven't discussed how to deliver the same Vue app to the client yet. To do that, we need to use webpack to bundle our Vue app. In fact, we probably want to use webpack to bundle the Vue app on the server as well, because:
+Jusqu'ici, nous n'avons pas encore discuté d'une méthode pour disposer de la même application Vue côté client. Pour cela, nous devons utiliser webpack pour fabriquer le bundle de notre application Vue. En fait, nous voulons probablement utiliser aussi webpack pour le bundle serveur, parce que :
 
-- Typical Vue apps are built with webpack and `vue-loader`, and many webpack-specific features such as importing files via `file-loader`, importing CSS via `css-loader` would not work directly in Node.js.
+- Les applications typiques Vue sont construites avec webpack et `vue-loader`, et beaucoup d'autres fonctionnalités spécifiques à webpack telles que l'import de fichiers via `file-loader`, ou encore l'import de CSS avec `css-loader` qui ne fonctionneraient pas directement en Node.js.
 
-- Although the latest version of Node.js fully supports ES2015 features, we still need to transpile client-side code to cater to older browsers. This again involves a build step.
+- Bien que la dernière version de Node.js supporte pleinement ES2015, nous avons toujours besoin de transpiler le code client pour prendre en charge les anciens navigateurs. Cela implique à nouveau une étape de build.
 
-So the basic idea is we will be using webpack to bundle our app for both client and server - the server bundle will be required by the server and used for SSR, while the client bundle is sent to the browser to hydrate the static markup.
+L'idée de base est donc que nous utiliserons webpack pour empaqueter notre application à la fois pour le client et le serveur - le bundle serveur sera nécessaire au serveur et utilisé pour le rendu côté serveur, alors que le bundle client sera envoyé au navigateur pour hydrater le DOM client.
 
 ![architecture](https://cloud.githubusercontent.com/assets/499550/17607895/786a415a-5fee-11e6-9c11-45a2cfdf085c.png)
 
-We will discuss the details of the setup in later sections - for now, let's just assume we've got the build setup figured out and we can write our Vue app code with webpack enabled.
+Nous allons discuter des détails de la mise en place dans les prochaines sections. Pour l'instant, considérons que nous avons configuré le build et que nous pouvons écrire le code de notre application Vue avec webpack.
 
-## Code Structure with webpack
+## Structure du code avec webpack
 
-Now that we are using webpack to process the app for both server and client, the majority of our source code can be written in a universal fashion, with access to all the webpack-powered features. At the same time, there are [a number of things](./universal.md) you should keep in mind when writing universal code.
+Maintenant que nous utilisons webpack pour développer l'application à la fois côté serveur et côté client, la majorité de notre code source peut être écrite d'une manière universelle, avec l'accès à toutes les fonctionnalités fournies par webpack. Pour autant, il y a [un certain nombre de choses](./universal.md) que vous devez garder à l'esprit en écrivant du code universel.
 
-A simple project would look like this:
+Voici ce à quoi pourrait ressembler un projet : 
 
 ``` bash
 src
@@ -70,24 +70,24 @@ src
 │   ├── Bar.vue
 │   └── Baz.vue
 ├── App.vue
-├── app.js # universal entry
-├── entry-client.js # runs in browser only
-└── entry-server.js # runs on server only
+├── app.js # point d'entrée universel
+├── entry-client.js # code exécuté côté navigateur exclusivement
+└── entry-server.js # code exécuté côté serveur exclusivement
 ```
 
 ### `app.js`
 
-`app.js` is the universal entry to our app. In a client-only app, we would create the root Vue instance right in this file and mount directly to DOM. However, for SSR that responsibility is moved into the client-only entry file. `app.js` simply exports a `createApp` function:
+`app.js` est l'entrée universelle de notre application. Dans une application exclusivement client, nous aurions créé l'instance de Vue principale directement dans ce fichier, et elle aurait été attachée au DOM. Pour le SSR cette responsabilité est déplacée dans le fichier d'entrée réservé au client. `app.js` exporte simplement une fonction `createApp`:
 
 ``` js
 import Vue from 'vue'
 import App from './App.vue'
 
-// export a factory function for creating fresh app, router and store
-// instances
+// exporte une fonction de fabrique pour créer de nouvelles instances 
+// de l'application, du routeur et du store
 export function createApp () {
   const app = new Vue({
-    // the root instance simply renders the App component.
+    // l'instance racine rend simplement le composant App.
     render: h => h(App)
   })
   return { app }
@@ -96,22 +96,22 @@ export function createApp () {
 
 ### `entry-client.js`:
 
-The client entry simply creates the app and mounts it to the DOM:
+L'entrée client crée simplement l'application et l'attache au DOM :
 
 ``` js
 import { createApp } from './app'
 
-// client-specific bootstrapping logic...
+// logique de démarrage spécifique client
 
 const { app } = createApp()
 
-// this assumes App.vue template root element has id="app"
+// nous partons du principe que l'élément racine du template App.vue a pour `id="app"`
 app.$mount('#app')
 ```
 
 ### `entry-server.js`:
 
-The server entry uses a default export which is a function that can be called repeatedly for each render. At this moment, it doesn't do much other than creating and returning the app instance - but later when we will perform server-side route matching and data pre-fetching logic here.
+L'entrée serveur utilise un export par défaut qui est une fonction pouvant être appelée de manière répétée à chaque rendu. Pour l'instant, le code ne fait pas grand chose de plus que créer et retourner une instance de l'application. Nous pourrons y intégrer plus tard la correspondance de route côté serveur et la logique de pré-chargement de données.
 
 ``` js
 import { createApp } from './app'

en/universal.md

@@ -1,31 +1,31 @@
-# Écrire du code universel (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).*
+# Écrire du code universel
 
-Before going further, let's take a moment to discuss the constraints when writing "universal" code - that is, code that runs on both the server and the client. Due to use case and platform API differences, the behavior of our code will not be exactly the same when running in different environments. Here we will go over the key things you need to aware of.
+Avant d'aller plus loin, prenons un moment pour discuter des contraintes lorsque l'on écrit du code « universel » - c'est à dire du code qui s'exécute à la fois côté serveur et côté client. En raison des différences d'API entre les deux plateformes, le comportement de notre code ne sera pas exactement le même selon l'environnement. Nous allons examiner les points clés dont vous devez avoir connaissance.
 
-## Data Reactivity on the Server
+## Réactivité des données côté serveur
 
-In a client-only app, every user will be using a fresh instance of the app in their browser. For server-side rendering we want the same: each request should have a fresh, isolated app instance so that there is no cross-request state pollution.
+Dans une application qui tourne exclusivement côté client, chaque utilisateur utilisera une nouvelle instance de l'application dans leur navigateur. Pour le rendu serveur nous voulons le même fonctionnement : chaque requête doit disposer d'une nouvelle instance d'application isolée. Ainsi il n'y aura pas de pollution liée à du partage d'état entre requêtes.
 
-Because the actual rendering process needs to be deterministic, we will also be "pre-fetching" data on the server - this means our application state will be already resolved when we start rendering. This means data reactivity is unnecessary on the server, so it is disabled by default. Disabling data reactivity also avoids the performance cost of converting data into reactive objects.
+Etant donné que le processus de rendu actuel doit être déterministe, nous allons aussi « pré-charger » les données sur le serveur. Cela signifie que l'état de notre application sera déjà disponible quand nous commençons le rendu. Cela signifie également que la réactivité des données est inutile côté serveur ; elle est donc désactivée par défaut. Désactiver la réactivité des données évite aussi le coût de performance d'une conversion de données en objets réactifs.
 
-## Component Lifecycle Hooks
+## Hooks de cycles de vie des composants
 
-Since there are no dynamic updates, of all the lifecycle hooks, only `beforeCreate` and `created` will be called during SSR. This means any code inside other lifecycle hooks such as `beforeMount` or `mounted` will only be executed on the client.
+Vu qu'il n'y a pas de mises à jour dynamiques, de tous les hooks de cycles de vie, seuls `beforeCreate` et `created` seront appelés pendant le rendu côté serveur. Cela signifie que tout code présent dans d'autres hooks tels que `beforeMount` ou `mounted` sera exécuté uniquement côté client.
 
-## Access to Platform-Specific APIs
+## Accès aux APIs spécifiques à la plateforme
 
-Universal code cannot assume access to platform-specific APIs, so if your code directly uses browser-only globals like `window` or `document`, they will throw errors when executed in Node.js, and vice-versa.
+Le code universel ne peut pas accéder aux APIs spécifiques à une plateforme. Ainsi, si votre code utilise directement les variables globales exclusives au navigateur comme `window` ou `document`, elles lèveront des erreurs si elles sont exécutées sur Node.js, et vice-versa.
 
-For tasks shared between server and client but use different platform APIs, it's recommended to wrap the platform-specific implementations inside a universal API, or use libraries that do this for you. For example, [axios](https://github.com/mzabriskie/axios) is an HTTP client that exposes the same API for both server and client.
+Pour les tâches partagées entre le serveur et le client, mais qui utilisent des APIs différentes selon la plateforme, il est recommandé d'encapsuler le code spécifique à la plateforme dans une API universelle, ou d'utiliser des bibliothèques qui le font pour vous. Par exemple, [axios](https://github.com/mzabriskie/axios) est un client HTTP qui présente la même API côté serveur et côté client.
 
-For browser-only APIs, the common approach is to lazily access them inside client-only lifecycle hooks.
+Pour les APIs exclusives au navigateur, l'approche habituelle est de les utiliser dans les hooks de cycle de vie exclusifs au client.
 
-Note that if a 3rd party library is not written with universal usage in mind, it could be tricky to integrate it into an server-rendered app. You *might* be able to get it working by mocking some of the globals, but it would be hacky and may interfere with the environment detection code of other libraries.
+Notez que si une bibliothèque tierce n'est pas écrite avec l'objectif d'être universelle, cela peut être délicat de l'intégrer dans une application rendue côté serveur. Vous *devriez* être capable de la faire fonctionner en substituant certaines variables globales, mais cela serait cavalier et pourrait interférer avec du code de détection d'environnement des autres bibliothèques.
 
-## Custom Directives
+## Directives personnalisées
 
-Most custom directives directly manipulate the DOM, and therefore will cause error during SSR. There are two ways to work around this:
+La plupart des directives personnalisées manipulent directement le DOM, et vont ainsi provoquer des erreurs durant le rendu côté serveur. Il y a deux façons d'éviter cela :
 
-1. Prefer using components as the abstraction mechanism and work at the Virtual-DOM level (e.g. using render functions) instead.
+1. Préférer l'utilisation de composants comme mécanisme d'abstraction et travailler au niveau du DOM Virtuel (par ex. en utilisant des fonctions de rendu)
 
-2. If you have a custom directive that cannot be easily replaced by components, you can provide a "server-side version" of it using the [`directives`](./api.md#directives) option when creating the server renderer.
+2. Si vous avez une directive personnalisée qui ne peut être facilement remplacée par des composants, vous pouvez en fournir une « version serveur » qui utilise l'option [`directives`](./api.md#directives) lors de la création du rendu serveur.