June 2018

src/v2/api/index.md

@@ -2533,4 +2533,4 @@ Used to denote a `<template>` element as a scoped slot, which is replaced by [`s
 
 ## Rendu côté serveur
 
-- Veuillez vous référer à la [documentation du package vue-server-renderer](https://github.com/vuejs/vue/tree/dev/packages/vue-server-renderer).
+- Veuillez vous référer à la [documentation du package vue-server-renderer](https://github.com/vuejs/vue/tree/dev/packages/vue-server-renderer).

src/v2/cookbook/avoiding-memory-leaks.md

@@ -41,7 +41,7 @@ new Vue({
   methods: {
     initializeChoices: function () {
       let list = []
-      // lets load up our select with many choices 
+      // lets load up our select with many choices
       // so it will use a lot of memory
       for (let i = 0; i < 1000; i++) {
         list.push({
@@ -123,7 +123,7 @@ new Vue({
 
 ## Details about the Value
 
-Memory management and performance testing can easily be neglected in the excitement of shipping quickly, however, keeping a small memory footprint is still important to your overall user experience. 
+Memory management and performance testing can easily be neglected in the excitement of shipping quickly, however, keeping a small memory footprint is still important to your overall user experience.
 
 Consider the types of devices your users may be using and what their normal flow will be. Could they use memory constrained laptops or mobile devices? Do your users typically do lots of in-application navigation? If either of these are true, then good memory management practices can help you avoid the worst case scenario of crashing a user’s browser. Even if neither of these are true, you can still potentially have degradation of performance over extended usage of your app if you are not careful.
 

src/v2/cookbook/client-side-storage.md

@@ -22,12 +22,14 @@ This example has one form field bound to a Vue value called `name`. Here's the J
 
 ``` js
 const app = new Vue({
-  el:'#app',
+  el: '#app',
   data: {
-    name:''
+    name: ''
   },
   mounted() {
-    if(localStorage.name) this.name = localStorage.name;
+    if (localStorage.name) {
+      this.name = localStorage.name;
+    }
   },
   watch: {
     name(newName) {
@@ -37,7 +39,7 @@ const app = new Vue({
 });
 ```
 
-Focus on the `mounted` and `watch` parts. We use `mounted` to handle loading the value from localStorage. To handle writing the data base, we watch the `name` value and on change, immediately write it. 
+Focus on the `mounted` and `watch` parts. We use `mounted` to handle loading the value from localStorage. To handle writing the data base, we watch the `name` value and on change, immediately write it.
 
 You can run this yourself here:
 
@@ -75,12 +77,16 @@ Now we've got two fields (again, bound to a Vue instance) but now there is the a
 const app = new Vue({
   el:'#app',
   data: {
-    name:'',
-    age:0
+    name: '',
+    age: 0
   },
   mounted() {
-    if(localStorage.name) this.name = localStorage.name;
-    if(localStorage.age) this.age = localStorage.age;
+    if (localStorage.name) {
+      this.name = localStorage.name;
+    }
+    if (localStorage.age) {
+      this.age = localStorage.age;
+    }
   },
   methods: {
     persist() {
@@ -106,30 +112,30 @@ As mentioned above, Local Storage only works with simple values. To store more c
   <h2>Cats</h2>
   <div v-for="(cat,n) in cats">
     <p>
-    <span class="cat">{{cat}}</span> <button @click="removeCat(n)">Remove</button>
+    <span class="cat">{{ cat }}</span> <button @click="removeCat(n)">Remove</button>
     </p>
   </div>
-  
+
   <p>
-    <input v-model="newCat"> 
+    <input v-model="newCat">
     <button @click="addCat">Add Cat</button>
   </p>
-  
+
 </div>
 ```
 
 This "app" consists of a simple list on top (with a button to remove a cat) and a small form at the bottom to add a new cat. Now let's look at the JavaScript.
 
 ``` js
 const app = new Vue({
-  el:'#app',
+  el: '#app',
   data: {
-    cats:[],
-    newCat:null
+    cats: [],
+    newCat: null
   },
   mounted() {
-    
-    if(localStorage.getItem('cats')) {
+
+    if (localStorage.getItem('cats')) {
       try {
         this.cats = JSON.parse(localStorage.getItem('cats'));
       } catch(e) {
@@ -140,13 +146,16 @@ const app = new Vue({
   methods: {
     addCat() {
       // ensure they actually typed something
-      if(!this.newCat) return;
+      if (!this.newCat) {
+        return;
+      }
+
       this.cats.push(this.newCat);
       this.newCat = '';
       this.saveCats();
     },
     removeCat(x) {
-      this.cats.splice(x,1);
+      this.cats.splice(x, 1);
       this.saveCats();
     },
     saveCats() {

src/v2/cookbook/debugging-in-vscode.md

@@ -24,6 +24,16 @@ Go to `config/index.js` and find the `devtool` property. Update it to:
 devtool: 'source-map',
 ```
 
+With Vue CLI 3 you need set `devtool` property inside `vue.config.js`:
+
+```js
+module.exports = {
+  configureWebpack: {
+    devtool: 'source-map'
+  }
+}
+```
+
 ### Launching the Application from VS Code
 
 Click on the Debugging icon in the Activity Bar to bring up the Debug view, then click on the gear icon to configure a launch.json file, selecting **Chrome** for the environment. Replace content of the generated launch.json with the following two configurations:
@@ -53,19 +63,19 @@ Click on the Debugging icon in the Activity Bar to bring up the Debug view, then
 
 1.  Set a breakpoint in **src/components/HelloWorld.vue** on `line 90` where the `data` function returns a string.
 
-![Breakpoint Renderer](/images/breakpoint_set.png)
+  ![Breakpoint Renderer](/images/breakpoint_set.png)
 
 2.  Open your favorite terminal at the root folder and serve the app using Vue CLI:
 
-```
-npm start
-```
+  ```
+  npm start
+  ```
 
 3.  Go to the Debug view, select the **'vuejs: chrome'** configuration, then press F5 or click the green play button.
 
 4.  Your breakpoint should now be hit as the new instance of Chrome opens `http://localhost:8080`.
 
-![Breakpoint Hit](/images/breakpoint_hit.png)
+  ![Breakpoint Hit](/images/breakpoint_hit.png)
 
 ## Alternative Patterns
 

src/v2/cookbook/dockerize-vuejs-app.md

@@ -0,0 +1,134 @@
+---
+title: Dockerize Vue.js App (EN)
+type: cookbook
+order: 13
+---
+
+## Simple Example
+
+<p>Cette page est en cours de traduction. Pour nous aider, vous pouvez participer sur <a href="https://github.com/vuejs-fr/vuejs.org" target="_blank">le dépôt GitHub dédié de Vuejs-FR</a>.</p>So you built your first Vue.js app using the amazing [Vue.js webpack template](https://github.com/vuejs-templates/webpack) and now you really want to show off with your colleagues by demonstrating that you can also run it in a Docker container.</p>
+
+Let's start by creating a `Dockerfile` in the root folder of our project:
+
+```docker
+FROM node:9.11.1-alpine
+
+# install simple http server for serving static content
+RUN npm install -g http-server
+
+# make the 'app' folder the current working directory
+WORKDIR /app
+
+# copy both 'package.json' and 'package-lock.json' (if available)
+COPY package*.json ./
+
+# install project dependencies
+RUN npm install
+
+# copy project files and folders to the current working directory (i.e. 'app' folder)
+COPY . .
+
+# build app for production with minification
+RUN npm run build
+
+EXPOSE 8080
+CMD [ "http-server", "dist" ]
+```
+
+It may seem reduntant to first copy `package.json` and `package-lock.json` and then all project files and folders in two separate steps but there is actually [a very good reason for that](http://bitjudo.com/blog/2014/03/13/building-efficient-dockerfiles-node-dot-js/) (spoiler: it allows us to take advantage of cached Docker layers).
+
+Now let's build the Docker image of our Vue.js app:
+
+```bash
+docker build -t vuejs-cookbook/dockerize-vuejs-app .
+```
+
+Finally, let's run our Vue.js app in a Docker container:
+
+```bash
+docker run -it -p 8080:8080 --rm --name dockerize-vuejs-app-1 vuejs-cookbook/dockerize-vuejs-app
+```
+
+We should be able to access our Vue.js app on `localhost:8080`.
+
+## Real-World Example
+
+In the previous example, we used a simple, zero-configuration command-line [http server](https://github.com/indexzero/http-server) to serve our Vue.js app which is perfectly ok for quick prototyping and _may_ even be ok for simple production scenarios. After all, the documentation says:
+
+> It is powerful enough for production usage, but it's simple and hackable enough to be used for testing, local development, and learning.
+
+Nevertheless, for realistically complex production use cases, it may be wiser to stand on the shoulders of some giant like [NGINX](https://www.nginx.com/) or [Apache](https://httpd.apache.org/) and that is exactly what we are going to do next: we are about to leverage NGINX to serve our vue.js app because it is considered to be one of the most performant and battle-tested solutions out there.
+
+Let's refactor our `Dockerfile` to use NGINX:
+
+ ```docker
+# build stage
+FROM node:9.11.1-alpine as build-stage
+WORKDIR /app
+COPY package*.json ./
+RUN npm install
+COPY . .
+RUN npm run build
+
+# production stage
+FROM nginx:1.13.12-alpine as production-stage
+COPY --from=build-stage /app/dist /usr/share/nginx/html
+EXPOSE 80
+CMD ["nginx", "-g", "daemon off;"]
+```
+
+Ok, let's see what's going on here:
+* we have split our original `Dockerfile` in multiple stages by leveraging the Docker [multi-stage builds](https://docs.docker.com/develop/develop-images/multistage-build/) feature;
+* the first stage is responsible for building a production-ready artifact of our Vue.js app;
+* the second stage is responsible for serving such artifact using NGINX.
+
+Now let's build the Docker image of our Vue.js app:
+
+```bash
+docker build -t vuejs-cookbook/dockerize-vuejs-app .
+```
+
+Finally, let's run our Vue.js app in a Docker container:
+
+```bash
+docker run -it -p 8080:80 --rm --name dockerize-vuejs-app-1 vuejs-cookbook/dockerize-vuejs-app
+```
+
+We should be able to access our Vue.js app on `localhost:8080`.
+
+## Additional Context
+
+If you are reading this cookbook, chances are you already know why you decided to dockerize your Vue.js app. But if you simply landed on this page after hitting the Google's `I'm feeling lucky` button, let me share with you a couple of good reasons for doing that.
+
+Today's modern trend is to build applications using the [Cloud-Native](https://pivotal.io/cloud-native) approach which revolves mainly around the following buzzwords:
+* Microservices
+* DevOps
+* Continuous Delivery
+
+Let's see how these concepts actually affect our decision of dockerizing our Vue.js app.
+
+### Effects of Microservices
+
+By adopting the [microservices architectural style](https://martinfowler.com/microservices/), we end up building a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms. These services are built around business capabilities and independently deployable by fully automated deployment machinery. 
+
+So, committing to this architectural approach most of the time implies developing and delivering our front-end as an independent service.
+
+### Effects of DevOps
+
+The adoption of [DevOps](https://martinfowler.com/bliki/DevOpsCulture.html) culture, tools and agile engineering practices has, among other things, the nice effect of increasing the collaboration between the roles of development and operations. One of the main problem of the past (but also today in some realities) is that the dev team tended to be uninterested in the operation and maintenance of a system once it was handed over to the ops team, while the latter tended to be not really aware of the system's business goals and, therefore, reluctant in satisfying the operational needs of the system (also referred to as "whims of developers").
+
+So, delivering our Vue.js app as a Docker image helps reducing, if not removing entirely, the difference between running the service on a deveveloper's laptop, the production environment or any environment we may think of.
+
+### Effects of Continuous Delivery
+
+By leveraging the [Continuous Delivery](https://martinfowler.com/bliki/ContinuousDelivery.html) discipline we build our software in a way that it can potentially be released to production at any time. Such engineering practice is enabled by means of what is normally called [continuous delivery pipeline](https://martinfowler.com/bliki/DeploymentPipeline.html). The purpose of a continuous delivery pipeline is to split our build into stages (e.g. compilation, unit tests, integration tests, performance tests, etc.) and let each stage verify our build artifact whenever our software changes. Ultimately, each stage increases our confidence in the production readiness of our build artifact and, therefore, reduces the risk of breaking things in production (or any other environment for that matters).
+
+So, creating a Docker image for our Vue.js app is a good choice here because that would represent our final build artifact, the same artifact that would be verified against our continuous delivery pipeline and that could potentially be released to production with confidence.
+
+## Alternative Patterns
+
+If your company is not into Docker and Kubernetes just yet or you simply want to get your MVP out the door, maybe dockerizing your Vue.js app is not what you need.
+
+Common alternatives are:
+* leveraging an all-in-one platform like [netlify](https://www.netlify.com/);
+* hosting your SPA on [Amazon S3](https://aws.amazon.com/s3/) and serving it with [Amazon CloudFront](https://aws.amazon.com/cloudfront/) (see [this](https://serverless-stack.com/chapters/deploy-the-frontend.html) link for a detailed guide).