Merge remote-tracking branch 'upstream/master' into working

Author: MachinisteWeb

fr/api.md

@@ -71,18 +71,18 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
 
   - `context.state`: (Object) L'état initial du store Vuex devrait être injecté dans la page sous la variable `window.__INITIAL_STATE__`. Le JSON en ligne est automatiquement désinfecté avec [serialize-javascript](https://github.com/yahoo/serialize-javascript) pour éviter les injections XSS.
 
-    Dans la 2.5.0+, les scripts injectés sont automatiquement retiré en mode production.
+    Dans la 2.5.0+, les scripts injectés sont automatiquement retirés en mode production.
 
   En plus, quand `clientManifest` est fourni, le modèle de page injecte automatiquement les éléments suivants :
 
   - JavaScript client et fichiers CSS nécessaires pour le rendu (avec les fragments asynchrones automatiquement déduits),
-  - utilisation optimale des indices de ressources `<link rel="preload/prefetch">` pour le rendu de la page.
+  - utilisation optimale des cibles de ressources `<link rel="preload/prefetch">` pour le rendu de la page.
 
   Vous pouvez désactiver toutes ces injections en passant `inject: false` au moteur de rendu.
 
   Voir également :
 
-  - [Utiliser un modèle de page](./basic.md#utiliser-un-modele-de-page)
+  - [Utiliser un modèle de page](./basic.md#utiliser-un-modèle-de-page)
   - [Injection manuelle des fichiers](./build-config.md#injection-manuelle-des-fichiers)
 
 - #### `clientManifest`
@@ -103,7 +103,7 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
 
   - 2.3.0+
 
-  Une fonction pour contrôler quels fichiers doivent avoir une ressource d'indice `<link rel="preload">` de générée.
+  Une fonction pour contrôler quels fichiers doivent avoir les cibles de ressource `<link rel="preload">` de générées.
 
   Par défaut, seuls les fichiers JavaScript et les fichiers CSS seront préchargés, car ils sont absolument nécessaires pour le démarrage de l'application.
 
@@ -135,9 +135,9 @@ Voyez l'[Introduction au moteur de dépaquetage](./bundle-renderer.md) et la [Co
 
   - 2.5.0+
 
-  Une fonction pour contrôler quels fichiers devraient avoir l'indice de ressource `<link rel="prefetch">` généré.
+  Une fonction pour contrôler quels fichiers devraient avoir la cible de ressource `<link rel="prefetch">` générée.
 
-  Par défaut, toutes les ressources sont des morceaux asynchrones qui vont être préchargés du fait que se sont des directives de basse priorité. Cependant vous pouvez personnaliser ce qui est préchargé afin d'avoir un meilleur contrôle sur l'utilisation de la bande passante. Cette option utilise une déclaration de fonction identique à celle de `shouldPreload`.
+  Par défaut, toutes les ressources sont des morceaux asynchrones qui vont être préchargées du fait que se sont des directives de basse priorité. Cependant vous pouvez personnaliser ce qui est préchargé afin d'avoir un meilleur contrôle sur l'utilisation de la bande passante. Cette option utilise une déclaration de fonction identique à celle de `shouldPreload`.
 
 - #### `runInNewContext`
 

fr/hydration.md

@@ -1,5 +1,7 @@
 # Hydratation côté client
 
+L'hydratation fait référence au processus côté client pendant lequel Vue va prendre la main sur le HTML statique envoyé par le serveur et le transformer en un DOM capable de réagir aux changements réactifs des données côté client.
+
 Dans `entry-client.js`, nous montons simplement l'application avec cette ligne :
 
 ``` js

fr/routing.md

@@ -119,9 +119,9 @@ import Foo from './Foo.vue'
 const Foo = () => import('./Foo.vue')
 ```
 
-Cela fonctionnera dans n'importe quel scénario si vous êtes en train de faire une application Vue uniquement pour le côté client. Toutefois, il y aura certaines limitations en l'utilisant avec du SSR. Premièrement, il faut résoudre tous les composants asynchrones à l'avance sur le serveur avant de faire le rendu, car sinon il y aura juste un emplacement vide dans le code HTML. Pour le côté client, il faut aussi faire cela avant de commencer l'hydratation des données, sinon il y aurait des erreurs d'incompatibilités sur le contenu.
+Jusqu'en Vue 2.5, cela fonctionnait pour les composants au niveau des routes. Cependant, avec les améliorations des algorithmes en 2.5+, cela fonctionne maintenant parfaitement partout dans votre application.
 
-Tout cela rend un peu compliquée l'utilisation des composants asynchrones à des endroits spécifiques dans votre application (nous allons probablement améliorer cela dans le futur). Toutefois, **cela fonctionne parfaitement si vous le faites au niveau de la route** - c.-à-d. d'utiliser les composants asynchrones dans la configuration des routes - car `vue-router` ira automatiquement résoudre les composants asynchrones nécessaires au bon fonctionnement de la route. Vous devez être sûr d'utiliser `router.onReady` sur le serveur et le client. Nous l'avons déjà fait pour le fichier d'entrée du serveur, il ne nous reste plus maintenant qu'à faire de même pour le fichier d'entrée du client :
+Notez qu'il est toujours nécessaire d'utiliser `router.onReady` côté client et côté serveur avant le renvoi / le montage de l'application, car le routeur doit résoudre les composants de route asynchrones à l'avance pour correctement déclencher les hooks des composants. Nous avons déjà fait cela dans notre entrée serveur et maintenant nous allons faire de même pour l'entrée cliente :
 
 ``` js
 // entry-client.js

fr/universal.md

@@ -18,7 +18,7 @@ Une autre chose à noter est que vous devriez éviter la création d'effets de b
 
 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.
 
-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.
+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/axios/axios) est un client HTTP qui présente la même API côté serveur et côté client.
 
 Pour les APIs exclusives au navigateur, l'approche habituelle est de les utiliser dans les hooks de cycle de vie exclusifs au client.