diff --git a/README.md b/README.md index 4830ce064d..bed7c6049c 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,4 @@ -# vuejs.org +# v2.vuejs.org > Important: This repository is for Vue 1.x and 2.x only. Issues and pull requests related to 3.x are managed in the [v3 doc repo](https://github.com/vuejs/docs-next). diff --git a/_config.yml b/_config.yml index d43089f9eb..375558d2bc 100644 --- a/_config.yml +++ b/_config.yml @@ -12,7 +12,7 @@ language: # URL ## If your site is put in a subdirectory, set url as 'http://yoursite.com/child' and root as '/child/' -url: https://vuejs.org +url: https://v2.vuejs.org root: / permalink: :year/:month/:day/:title/ tag_dir: tags @@ -144,7 +144,7 @@ markdown: ## Docs: https://hexo.io/docs/one-command-deployment deploy: type: git - repository: git@github.com:vuejs/vuejs.org.git + repository: git@github.com:vuejs/v2.vuejs.org.git feed: type: atom diff --git a/package.json b/package.json index 6ed23f8991..b68a583fb8 100644 --- a/package.json +++ b/package.json @@ -1,5 +1,5 @@ { - "name": "vuejs.org", + "name": "v2.vuejs.org", "private": true, "hexo": { "version": "3.8.0" diff --git a/src/_posts/common-gotchas.md b/src/_posts/common-gotchas.md index a8abf2314e..c4ed741291 100644 --- a/src/_posts/common-gotchas.md +++ b/src/_posts/common-gotchas.md @@ -15,7 +15,7 @@ Most of the time, when you change a Vue instance's data, the view updates. But t 2. When you modify an Array by directly setting an index (e.g. `arr[0] = val`) or modifying its `length` property. Similarly, Vue.js cannot pickup these changes. Always modify arrays by using an Array instance method, or replacing it entirely. Vue provides a convenience method `arr.$set(index, value)` which is syntax sugar for `arr.splice(index, 1, value)`. -Further reading: [Reactivity in Depth](/guide/reactivity.html) and [Array Change Detection](http://vuejs.org/guide/list.html#Array-Change-Detection). +Further reading: [Reactivity in Depth](/guide/reactivity.html) and [Array Change Detection](/guide/list.html#Array-Change-Detection). ### When is the DOM updated? @@ -33,6 +33,6 @@ Further reading: [Component Option Caveats](/guide/components.html#Component-Opt All Vue.js templates are valid, parsable HTML markup, and Vue.js relies on spec-compliant parsers to process its templates. However, as specified in the standard, HTML is case-insensitive when matching tag and attribute names. This means camelCase attributes like `:myProp="123"` will be matched as `:myprop="123"`. As a rule of thumb, you should use camelCase in JavaScript and kebab-case in templates. For example a prop defined in JavaScript as `myProp` should be bound in templates as `:my-prop`. -Further reading: [camelCase vs. kebab-case](http://vuejs.org/guide/components.html#camelCase-vs-kebab-case). +Further reading: [camelCase vs. kebab-case](/guide/components.html#camelCase-vs-kebab-case). We are also discussing the possibility of eliminating this inconsistency by resolving props and components in a case-insensitive manner. Join the conversation [here](https://github.com/vuejs/vue/issues/2308). diff --git a/src/_posts/why-no-template-url.md b/src/_posts/why-no-template-url.md index f6fbabe2dd..8ffacabbbb 100644 --- a/src/_posts/why-no-template-url.md +++ b/src/_posts/why-no-template-url.md @@ -13,8 +13,8 @@ First, it allows us to write our template in a separate HTML file. This gives us Second, because `templateURL` loads the template via Ajax at runtime, you don't need a build step in order to split up your files. This is convenient during development, but comes at a serious cost when you want to deploy it to production. Before HTTP/2 is universally supported, the number of HTTP requests is still probably the most critical factor in your app's initial load performance. Now imagine you use `templateURL` for every component in your app - the browser needs to perform dozens of HTTP requests before even being able to display anything! In case you don't know, most browsers limit the number of parallel requests it can perform to a single server. When you exceed that limit, your app's initial rendering will suffer for every extra round trip the browser has to wait for. Sure, there are build tools that can help you pre-register all those templates in `$templateCache` - but that shows us a build step is, in fact, inevitable for any serious frontend development. -So, without `templateURL`, how do we deal with the development experience problem? Writing templates as inline JavaScript strings is terrible, faking templates with `