Traduction data.md
#8
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Bruno Lesieur <[email protected]>
Signed-off-by: Bruno Lesieur <[email protected]>
Signed-off-by: Bruno Lesieur <[email protected]>
Kocal
reviewed
May 20, 2017
en/data.md
Outdated
|
|
||
| To address this, the fetched data needs to live outside the view components, in a dedicated data store, or a "state container". On the server, we can pre-fetch and fill data into the store before rendering. In addition, we will serialize and inline the state in the HTML. The client-side store can directly pick up the inlined state before we mount the app. | ||
| Pour résoudre cela, les données pré-chargées doivent vivre en dehors de la vue du composant, dans un gestionnaire de données, ou dans un « gestionnaire d'état ». Côté serveur, nous pouvons pré-charger et remplir les données dans le gestionnaire de donnée avant le rendu. De plus, nous allons en sérialiser et en injecter l'état dans le HTML. Le gestionnaire de données côté client pourra directement récupérer l'état depuis le HTML avant que l'application ne soit montée. |
There was a problem hiding this comment.
De plus, nous allons sérialiser et injecter l'état dans le HTML
en/data.md
Outdated
| @@ -44,7 +44,7 @@ export function createStore () { | |||
| } | |||
| ``` | |||
|
|
|||
| And update `app.js`: | |||
| et mettons à jour `app.js`: | |||
en/data.md
Outdated
|
|
||
| So, where do we place the code that dispatches the data-fetching actions? | ||
| Donc, ou devons nous appeler le code en charge de l'action de pré-chargement ? |
en/data.md
Outdated
|
|
||
| The data we need to fetch is determined by the route visited - which also determines what components are rendered. In fact, the data needed for a given route is also the data needed by the components rendered at that route. So it would be natural to place the data fetching logic inside route components. | ||
| Les données que nous avons besoin de pré-charger sont déterminées par la route visitée, qui va aussi déterminée quel composant va être rendu. En fait, les données nécessaire a une route donnée sont aussi les données nécessaire au composant pour être rendu pour une route. Aussi il serait naturel de placer la logique de pré-chargement à l'intérieur des composants de route. |
There was a problem hiding this comment.
va aussi déterminer
données nécessaires
données nécessaires
en/data.md
Outdated
|
|
||
| In `entry-server.js` we can get the components matched by a route with `router.getMatchedComponents()`, and call `asyncData` if the component exposes it. Then we need to attach resolved state to the render context. | ||
| Dans `entry-server.js` nous pouvons obtenir des composants qu'ils concordent avec une route grâce à `router.getMatchedComponents()`, et appeler `asyncData` si le composant l'expose. Nous avons ensuite besoin d'attacher l'état résolue au contexte de rendu. |
There was a problem hiding this comment.
des composants qui concordent
l'état résolu
en/data.md
Outdated
| @@ -125,7 +125,7 @@ export default context => { | |||
| reject({ code: 404 }) | |||
| } | |||
|
|
|||
| // call asyncData() on all matched route components | |||
| // appeler `asyncData()` sur toutes les routes concordant | |||
en/data.md
Outdated
| // When we attach the state to the context, and the `template` option | ||
| // is used for the renderer, the state will automatically be | ||
| // serialized and injected into the HTML as window.__INITIAL_STATE__. | ||
| // Après que chaque hook de pré-chargement soit résolue, notre store est maintenant |
en/data.md
Outdated
| // rempli avec l'état nécessaire au rendu de l'application. | ||
| // Quand nous attachons l'état au contexte, et que l'option `template` | ||
| // est utilisée pour faire le rendu, l'état va automatiquement être | ||
| // sérialisé et injecté dans le HTML pour alimenter window.__INITIAL_STATE__. |
There was a problem hiding this comment.
être sérialisé et injecté dans le HTML en tant que
window.__INITIAL_STATE__.
n'était pas bon ?
Kocal
requested changes
May 20, 2017
# Conflicts: # en/structure.md Signed-off-by: Bruno Lesieur <[email protected]>
# Conflicts: # en/data.md Signed-off-by: Bruno Lesieur <[email protected]>
Signed-off-by: Bruno Lesieur <[email protected]>
Signed-off-by: Bruno Lesieur <[email protected]>
|
J'ai refait une relecture ici. Merci beaucoup @Kocal pour tes points ! Il me reste un doute pour « jeu de logique », c'est bien de cela dont il est question ? |
|
Pas de problème :) Mmmh, pour Cependant, je ne vois pas trop pourquoi |
Kocal
approved these changes
May 27, 2017
Signed-off-by: Bruno Lesieur <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
C'est le temps de la review !