Vuejs.org: 2.0 Docs

[chrisvfritz]

Guidelines for writing official Vue docs

These are not immutable dictates, but rather a place to consolidate our evolving consensus. If there's an item you strongly disagree with, please do discuss it below and this section will be updated to better explain and reflect the new consensus.

• Use 2-space indentation in examples for all languages.
• Use only ES5 features in JavaScript examples unless the example already requires a build process or demonstrates a plugin that is almost exclusively used in applications complex enough to warrant a build process (e.g. vuex or vue-router).
• Adhere to ferross/standard in JavaScript examples.
• Adhere to Google's style guide for HTML and CSS. You probably don't have to actually read it, because wildly diverging styles are less common in these languages, but this resource can be used to end bikeshedding.
• Use el: '#app' in place of el: 'body' to encourage the thinking that you are able to limit Vue's scope on your page.
• Use JSFiddle exclusively for embedded and linked demos. The only exception is WebpackBin may be used to demonstrate code that requires a build step, such as the .vue file syntax or JSX.
• Use https://unpkg.com/vue@next/dist/vue.js to reference Vue 2.0 in all fiddles.
• Use CDN links with hardcoded versions to reference companion libraries.
• Reference linked resources that do not yet exist with !!TODO: ... in place of the URL. The !! prefix makes them distinguishable from todo list examples in a search. 😛
• When referencing the library, use Vue.js in page titles and Vue for every subsequent mention.
• When referencing companion libraries, use the name on GitHub and NPM (e.g. vue-router rather than Vue Router or VueRouter).

Contributing

1. Edit this comment to change unclaimed to @yourUsername so everyone knows you're working on a file.
2. Commit directly to the 2.0 branch
3. Try to edit only one file (the one you claimed) at a time.
4. When ready to push, git fetch origin 2.0, git rebase origin/2.0, then git push origin 2.0. (Yes, we're skipping code review for now. Let's just get something in place for this first pass.)
5. Update this comment to put a check next to the file you updated.
   

   Guide Updates

This list is incomplete and only represents the first pass we'll make in rewriting the docs for 2.0. It's very likely we'll want to remove/add/reorganize many pages and sections. As more issues become apparent in the process of writing docs, we can discuss them here in this issue.

• [x] @chrisvfritz 0. Installation
• [x] @chrisvfritz 1. Getting Started
• [x] @chrisvfritz 2. Overview
• [x] @chrisvfritz 3. The Vue Instance
• [x] @posva 4. Data Binding Syntax
• [x] @chrisvfritz 5. Computed Properties
• [x] @chrisvfritz 6. Class and Style Bindings
• [x] @chrisvfritz 7. Conditional Rendering
• [x] @chrisvfritz 8. List Rendering
• [x] @chrisvfritz 9. Methods and Events Handling
• [x] @chrisvfritz 10. Form Input Bindings
• [x] @chrisvfritz 11. Transitions
• [x] @chrisvfritz 12. Components
• [x] @chrisvfritz 13. Reactivity
• [x] @chrisvfritz 14. Custom Directives
• [x] @chrisvfritz 15. Custom Filters
• [x] @posva 16. Mixins
• [x] @kazupon 17. Plugins
• [x] @chrisvfritz 18. Building Large-Scale Apps. This is being split up into several sections:
  
  
  
  • [x] Single-File Components
  
  
  • [x] Routing
  
  
  • [x] State Management
  
  
  • [x] Unit Testing
  
  
• [x] @chrisvfritz 19. Comparison with Other Frameworks
• [x] @chrisvfritz 20. Join the Vue Community!
• [x] @chrisvfritz render functions
  
  
  
  • VNode API ^{moved to API section}
  
  
• [x] @chrisvfritz Server-Side Rendering
• Integrating vue-router, vuex, and vue-server-renderer ^{SSR docs link to documentation and examples for this}
• [x] @chrisvfritz 1.0 Migration Guide

Misc topics that need better coverage

• [x] @chrisvfritz v-once
• [x] @chrisvfritz how to do <script type="text/x-template" id="foo"> with template: '#foo'
• v-cloak ^{not _very_ frequently used, so probably fine to just be in API doc}
• v-pre ^{not _very_ frequently used, so probably fine to just be in API doc}
• [x] @chrisvfritz ref in non-v-for contexts?

API Updates

Resources:

• Changes Issue
• Updated Guide
• Feature Unit Tests
• Flow Types

Sections:

• [x] @fadymak Global Config
• [x] @fadymak Global API
• [x] Instance Options
  
  
  
  • [x] @fadymak Data
  
  
  • [x] @fadymak DOM
  
  
  • [x] @fadymak Lifecycle Hooks
  
  
  • [x] @fadymak Assets
  
  
  • [x] @fadymak Misc
  
  
• [x] @kazupon Instance Properties
• [x] Instance Methods
  
  
  
  • [x] @kazupon Data
  
  
  • [x] @kazupon Events
  
  
  • [x] @kazupon DOM
  
  
  • [x] @kazupon Lifecycle
  
  
• [x] @kazupon Directives
• [x] @kazupon Special Elements
• [x] @yyx990803 Special Attributes
• unclaimed VNode just point to vnode source
• unclaimed Server-Side Rendering just point to GitHub

[yyx990803]

Re using el: body: let's keep them to ids. I want to encourage the thinking that you are able to limit Vue's scope on your page.

[chrisvfritz]

@yyx990803 👍 Updated the guidelines.

[zigomir]

I went over 2. Overview I think everything still holds for Vue 2.0. Examples work fine. One thing I'm not really sure is if Vue 2.0 is also supporting IE9 and above? If that's true then we might not need to change anything in overview.md file.

[chrisvfritz]

@zigomir I just went through the Overview section and mostly just added more links, but it did indeed need very little change. 😃

[chrisvfritz]

@yyx990803 In writing some documentation for lifecycle hooks, it occurred to me that all of them are in pairs (e.g. beforeMount/mounted and beforeDestroy/destroyed), except for init and created. What would you think about renaming init to beforeCreate for consistency? That may also make it more obvious that at this stage, nothing has actually been initialized.

[zkwolf]

In computed.md line 72, it should be vm.message = 'Goodbye'

[chrisvfritz]

@zkwolf Thanks!! Good catch. 😄 Just fixed it.

[zkwolf]

@chrisvfritz And ... In list.md Object v-for section, you forget change val to value

[chrisvfritz]

@zkwolf Woohoo! Fixed. 😃 Thanks again for your excellent eye.

[chrisvfritz]

@yyx990803 Is there a way to add new keyCode aliases in 2.0? The only gettable directives seem to be model and show.

[chrisvfritz]

@yyx990803 Also, it looks like transition no longer applies a -transition class. I didn't see this explicitly listed as a planned deprecation, so double checking. Should users just add their own always-on class if they want one?

[yyx990803]

@chrisvfritz yeah, overlooked the custom keyCodes usage. Implemented in https://github.com/vuejs/vue/commit/4fe51a75a94464075055b45550a05e4680bb2b9f. It is now exposed as Vue.config.keyCodes.

Yes, transition no longer applies the automatic class. The user can either provide the always-on class themselves, or define the transition property in enter-active/leave-active classes.

[MeiYuanChen]

1.vue-server-renderer can solve 'seo' question?
2.Why not ’Guidelines Vue docs‘ inside vue-server-renderer?

[chrisvfritz]

@MeiYuanChen Moving all the docs into a Vue app would take a lot of time to port and the advantages wouldn't be that significant at this point. Hexo is working for us just fine for now. 😃

[zkwolf]

In forms.md line185, it should be <span>Selected: {{ selected }}</span>

[chrisvfritz]

@zkwolf Another excellent catch! Fixed.

[cezaraugusto]

Hi Vue team, two questions:

1. Are those docs open for outside contributors? If so, is the above steps mentioned by @chrisvfritz enough to contribute? Is there something else?
2. If I plan to translate the current documentation: would it be better to wait until 2.0? Is it a breaking version or just improvements? Which things should I be aware of?

Regards

[chrisvfritz]

Hi @cezaraugusto! Great questions. 😃

1. Feedback is definitely welcome, but major contributions from outside the core team won't be practical until the first draft rewrites have all been done. The reason is that a lot of internal discussions are fueling the rewrite, which then often lead to API changes, which then lead to more rewrites. 😜 For the docs that already have a check mark next to them, the first draft has been completed and @zkwolf and others have already found a lot of room for improvement. If you also want to look them over, we'd love to hear your thoughts.
2. For translation, I would probably wait until Vue reaches at least the RC stage, when the API will be very stable and the source documentation will be much less likely to drastically change.

Let me know if that fully addresses your questions.

[cezaraugusto]

Sure @chrisvfritz, thanks for clarifying. Great job so far 👌 , am following closely 👀 .

[theotherzach]

Use only ES5 features in JavaScript examples unless the example already requires a build process or demonstrates a plugin that is almost exclusively used in applications complex enough to warrant a build process (e.g. vuex or vue-router).

Thank you so, so, so, so, so, so, so, so, so, so, so, SO very much for this. I teach Vue to people as an introduction to frontend JavaScript, often in programming communities with little to no culture of JS tooling, so this is huge for me. Thank you thank you thank you thank you thank you.

[miljan-aleksic]

@chrisvfritz, should I open a ticket about issues I found or comment them here first?

[chrisvfritz]

@miljan-aleksic You can just comment here. Thanks for your help!

[miljan-aleksic]

Ok, so far is pretty good! Just some minor details:

1) This comment is difficult to read, should be splited in multiple lines. The same goes for the other comments of the same example.

2) This sentence is not finished.

3) After Components guide, the next link goes to Reactivity in Depth instead of Render Functions. I guess those links should be reviewed at once after all done.

4) Seems this function is misspelled or missing in the example.

[chrisvfritz]

@miljan-aleksic Thanks! All of those are now fixed.

[miljan-aleksic]

@chrisvfritz, the Render Function optional object corresponding to the template attributes differs slightly if using a component or not. Example, the on: { click (...) } event listener will not work on a component while will do on an anchor tag for example. I think it has to do with the fact that v-on does not longer listen to native dom events, but is it kind of confusing why it does with the native dom.

Assuming is not a bug, I think it should be documented to avoid confusions and commented in the render options example.

[yyx990803]

@miljan-aleksic 2.0 v-on listens to component events only when used on a component. But in beta.3 you will be able to do @click.native to explicitly listen to native events.

[chrisvfritz]

@miljan-aleksic This behavior, now including the .native modifier, is covered in Custom Events section of the components guide. Let me know if you think there's anything we could make clearer there. 😃

[miljan-aleksic]

@chrisvfritz, @yyx990803, thank you, that's perfect. How should the modifiers be specified in the object definion? An example in the doc would be useful.

BTW, that example code is getting too big and difficult to read. What about defining it's first level arguments alone and in a separate example go deeper into the details?

[chrisvfritz]

@miljan-aleksic In render functions, nativeOn will be used for native events on components and we will be adding something to the docs about it. 😃

Which example code are you referring to?

[miljan-aleksic]

I'm refering to the same render functions example. nativeOn it's only for one modifier, I assume then preventOn its also one of the options, etc.

[chrisvfritz]

@miljan-aleksic No, nativeOn is made available because there'd be no other way to listen to native events. For .prevent, you'd simply include event.preventDefault() in the event handler. For key modifiers such as .enter, you'd instead manually check for the correct key code (e.g. if (event.keyCode === 13) { /* ... */ })

[miljan-aleksic]

@chrisvfritz, got it, makes sense. Thanks.

[miljan-aleksic]

@chrisvfritz, it is possible to use directives on render functions, eg. v-if? If not, perhaps it should be mentioned that the rest of directives not commented in the example are not supported.

[chrisvfritz]

@miljan-aleksic No, wherever something can be easily accomplished with plain JavaScript, we don't add a proprietary way to do the same thing. In the case of v-if and v-for for example, you would instead write something like this:

render: function (h) {
  if (this.items.length) {
    return h('ul', this.items.map(function (item) {
      return h('li', item.name)
    }))
  } else {
    return h('p', 'No items found.')
  }
}

I agree it'll be good to add a note reminding people about plain JavaScript alternatives. 👍

[miljan-aleksic]

@chrisvfritz, thanks for the clarification. Yes, it would be good as the first impression is that a render function options replaces all the features you would easily do in a template.

[chrisvfritz]

@miljan-aleksic @theotherzach @cezaraugusto @zkwolf Just pushed up a significant update, especially in the transitions docs, which should now be 100% up-to-date (along with everything else). Would love to hear your thoughts if you find the time to take a look.

[miljan-aleksic]

Great @chrisvfritz!

Seems the #animated-number-demo input allows going number up or number down, but the effect to be noticable requires at least 20 numbers difference. The first impression is that the demo doesn't work.

[chrisvfritz]

@miljan-aleksic Great point! I just added step="20" to the animated number inputs on that page.

[miljan-aleksic]

@chrisvfritz, a JSX example using functional components would be helpful. For example the ctx.children is a function that will be not be executed automatically and this kind of code would fail, return(<div>{ children }</div>). While just passing the function to the $createElement method works.

[p-adams]

ref in non-v-for contexts?
So something like this? http://codepen.io/p-adams/pen/bZxbNz

[chrisvfritz]

@miljan-aleksic I'll either update with an example - or possible just change the JSX plugin so that <div>{ children }</div> will not fail.

@p-adams Exactly. There isn't currently an example of that in the guide, but I have yet to find a really great place to add it.

[theotherzach]

Wow, that transitions page really has grown. For somebody new to Vue, this section is going to be a bit like a learning cliff. Not sure if there is much to be done about that, the new transition abstract component is very powerful and welcome, but it increases the number of required concepts in order to get started with transitions. Would it make sense to add a transition version of /guide/index.html#All-Together-Now with 1 or 2 focused examples on common use cases with minimal explanation. These are the transitions I use all the darn time:

• transitioning a single element out
• filtering a list as the user types (the staggering example)

Edit:
I'm constantly wanting to wait for another transition to finish up before introducing a new UI component, and I often cannot use dynamic components and out-in to accomplish this. Not sure if it's guide worthy, but I really like how the new transition system allows us to wait for ANY transition to finish.

http://codepen.io/theotherzach/pen/mEXWQd?editors=1010

[chrisvfritz]

@theotherzach

Organization of the transitions guide

The length of this section doesn't really increase the number of concepts required just to get started. In the very common use case you mentioned of fading an element in/out, people could actually read less than 200 words of that page (including code examples) and already know how to do that. If that's all they need at that moment, I think it's even fine if they stop there.

If someone is not that interested in mastering the entire transition system, the docs are also very searchable, so that they can type something like "list transitions" and immediately be taken to the right place in the page, read a few hundred words to learn just enough, then get back to their app.

More examples for common use cases

In the guide, we do generally want to keep examples as simple as possible, with only enough complexity to demonstrate a single new concept in a non-trivial way. I'd like to keep it this way, but we have heard from many in the community that people want more examples integrating features for common use cases - and also not-as-common but really interesting/cool use cases.

We definitely want to provide that! It probably won't be in the guide though, but in another resource like an official Vue Cookbook, which would be dedicated to examples that already assume knowledge of core Vue concepts. @LinusBorg actually deserves credit for the idea and he's been collecting examples of what people are appreciating and asking for. Unfortunately, visible work might not start on this until the RC stage or possibly even after release.

Overall length/organization of the guide

One thing we're very happy about is that in the current guide, people can dive in and become productive building non-trivial applications in less than a day. That's actually how I got started with Vue! For 2.0 though, we're building out more and more advanced sections, so that digesting it all in a single day is less feasible.

To resolve this, I'm thinking of moving the Components page before the 2 Transitions pages, then possibly splitting everything up into 3 main sections: something like Essentials (for everything up to and including Components), Advanced (for Transitions onward), and Meta (for the Comparisons and Join the Community pages). Although I don't actually consider transitions that advanced, I'm still considering putting them there because I don't feel they're "essential" - they help you build prettier things, but aren't required for most prototyping.

This way, developers (especially those with relatively less experience) will have a natural stopping point where they can take a break before they feel overwhelmed. At this point, they'll also have learned enough to read and build most Vue components.

[miljan-aleksic]

@chrisvfritz, the guide separation is looking good! Great idea.

I noticed that when entering Custom Directives section the v-focus example does his thing and focus the input but in the process scrolls your page down if you have smaller screens. It could be avoided if the input is set first, just after the introduction text, and then below the code.

I know it would not follow the guide structure but otherwise you are forcing the user to scroll up after realizing what actually happened.

[chrisvfritz]

@miljan-aleksic That's a good point - revised now.

[p-adams]

Is the guide to using the new virtual-dom feature going to have it's own section? I feel like a feature such as this deserves quite a thorough guide with plenty of examples.

[chrisvfritz]

@p-adams If you're referring to the VNode API, we will be documenting it, possibly added to the render function section, since that's the context where it's most likely to be used.

[dan-gamble]

All i can say after cloning and running this is wow! Absolutely awesome job on the new docs and Vue 2 overall and i've only read the new transition page so far..

[blocka]

I would like to point out two things in comparison docs...I hope this is right place for this.
The first is the claim that "React has made strides in this area, but has yet to produce a production-ready, out-of-the-box solution for new projects." Actually, react as something like this, called "create-react-app", which is certainly production ready. Perhaps there should be a comparison between vue-cli and create-react-app?

The second is the issue with if statements vs ternary statements in jsx. While this is definitely an issue, there is a solution on the horizon, in the form of do expressions. With do expressions, a if/else can be wrapped into one expression and used in JSX (or in array functions for that matter), which makes the syntax a tiny bit more palatable.

For example:

<div className='myComponent'>
    {do {
      if(color === 'blue') { <BlueComponent/>; }
      if(color === 'red') { <RedComponent/>; }
      if(color === 'green') { <GreenComponent/>; }
    }}
  </div>

There is still "syntax tax", but it's definitely nicer looking then hoisting or using ternaries.

[chrisvfritz]

@blocka Thanks for taking a look at this! The comparisons section is definitely something the team will be discussing in more detail before the final release. Regarding those specific items:

Production use of create-react-app

We're aware of this project, but even their documentation only recommends it for getting started with React. It's currently missing many features vital for non-trivial projects, most notably the lack of support for any testing, CSS preprocessors, ES7/2016 features such as the object spread operator and decorators (both are often used quite extensively within React projects), and hot module reloading.

If I were starting a new React project today, I can't think of a scenario where I would use it - and even if I were forced to, I'd have to immediately eject and modify the build process before any significant work could begin.

I think adding a note to let people know we are aware of this project would be good though. 👍

Do expressions for cleaner JSX

I'm definitely excited about do expressions. They'll help a little, but they're currently at stage 0, which is a little more unstable than many projects are willing to work with at this point. I'll add a note about them nonetheless.

[gaearon]

We're aware of this project, but even their documentation only recommends it for getting started with React.

This is not the case. It is explicitly labeled “production-ready”. Yes, it is currently catered more to beginners than to advanced users, but even advanced users find it useful:

(This is from the post-eject survey.)

It's currently missing many features vital for non-trivial projects, most notably the lack of support for

any testing

The support for testing has been merged, and while we may tweak a few things before releasing it officially, it is going to be added. I believe README explicitly says we _intend_ to add testing.

CSS preprocessors

You can run your existing preprocessors just fine if you want to, and import resulting css files. We don’t intend them to be part of the default setup but they’re perfectly usable from create-react-app, with the same workflow that people have been using for years.

ES7/2016 features such as the object spread operator

This is incorrect, spread operator has been supported from the very first release.

and decorators (both are often used quite extensively within React projects)

Decorators are currently not officially supported by Babel, have weird hard-to-diagnose issues, and the spec is still changing. In my experience many people get confused by decorators, and I’m not comfortable including them while they are so unstable in practice.

and hot module reloading.

It’s enabled for CSS, but hot reloading for React components is currently too flaky. (I hope I qualify to speak about that 😄 .)

We care about providing the complete cohesive experience, not just picking the latest popular things. So yes, we leave something out, but we do it on purpose, and not because the tool is half-baked.

[chrisvfritz]

Thanks for the input @gaearon! This is definitely helpful in making sure we don't misrepresent the create-react-app project. 😃 Some quick notes:

• Object Spread Operator: The support for the object spread operator was definitely a misreading on my part - I apologize for that.
• CSS Preprocessors: I would personally prefer not to maintain multiple parallel build systems, but I can see your point that it is possible.
• Production-Ready vs Development-Ready: I did see that it's ready for production and I don't dispute that. The question for me was more whether it was _development-ready_. With some of the missing features, it wouldn't (currently) be possible for me to generate a new client project and start coding right away, like I can with vue-cli's Webpack template. I'd have to first eject and spend considerable time enhancing the build process and development environment. The addition of out-of-the-box testing goes most of the way in resolving this though, so I'll write assuming it'll be included by the time these docs are released.

Project Goals

I think this is a misconception that could be resolved by updates to the README. My understanding that it was mainly intended for onboarding came from the "Why Use This?" section, which starts with "If you’re getting started with React [...]" - the bolding is not mine.

Testing Support

Glad to hear that it's on the way!

believe README explicitly says we intend to add testing.

I didn't see any explicit mention of this. The section I think you may be referring to contains 3 qualifiers (italics are mine):

_Some_ of them _might_ get added in the future _if_ they are stable, are useful to majority of React apps, don't conflict with existing tools, and don't introduce additional configuration.

This doesn't convey a sense of inevitability to me, but a tweaking to the wording in the first clause might be helpful if you wish to - something like: "We're actively working on the features above and they will be added when [...]".

Thanks Again 😄

Thanks again for the feedback! As we revise this section a little more, I'll be sure to mention/tweet you so you can take another look.

[gaearon]

Thanks for the feedback. We’ll tweak messaging as we get to 1.0 and make this thing more official.

[VyaWave]

Good,Good,But Where is The Chinese Docs ? ? ? @yyx990803

[chrisvfritz]

@AyAmeng As far as I know, translation to Chinese hasn't started yet. When it does, would you like to help?

[smithb1994]

At https://rc.vuejs.org/guide/components.html#Form-Input-Components-using-Custom-Events please consider rewriting the last example from:

template: '\
    <div class="form-group">\
      <label v-bind:for="randomId">{{ label }}:</label>\
      <input v-bind:id="randomId" v-bind:value="value" v-on:input="onInput">\
    </div>\
  '

and change it to a more readable:

template:
    '<div class="form-group">' +
      '<label v-bind:for="randomId">{{ label }}:</label>' +
      '<input v-bind:id="randomId" v-bind:value="value" v-on:input="onInput">' +
    '</div>'

Thanks

[blocka]

Even better

template:
    `<div class="form-group">
      <label v-bind:for="randomId">{{ label }}:</label>
      <input v-bind:id="randomId" v-bind:value="value" v-on:input="onInput">
    </div>`

unless for some reason es6 is avoided in the docs.

[smithb1994]

Similar template readability complaint at https://rc.vuejs.org/guide/components.html#Components-and-v-for

[smithb1994]

At https://rc.vuejs.org/guide/components.html#Async-Components do components accept a returned promise? It didn't indicate whether it did.

[smithb1994]

Same template complaint at https://rc.vuejs.org/guide/components.html#Cheap-Static-Components-with-v-once as well.

[LinusBorg]

@blocka: we use ES5 in the guide (See the second bullet point in the OP), so no template strings.

@smithb1994 Personally, I don't think your way of writing the template is nessessarily more readable, but we will see how he others feel about it.

[smithb1994]

There is no lifecycle diagram at https://rc.vuejs.org/guide/instance.html#Lifecycle-Diagram

[chrisvfritz]

@smithb1994

• Template style: It sounds like just a matter of preference (and your version actually has _more_ syntax characters), so we won't be changing it for now.
• Lifecycle diagram: We are aware. These docs are work-in-progress and if you look at the src for the missing image, you'll actually see !!TODO: EVAN WILL NEED TO UPDATE /images/lifecycle.png. 😉
• Promises with Async Components: You cannot return a promise in async components. The described interface is the only one available. You can still easily use a promise like this though. Edit: Evan just added this feature to rc4. 😃

[chay22]

Few lines under here (on list) tells slots as in context, contains slot object while I have to call it as a function first to get the object returned. Am I missing something?

Also for the lack of directives in #render() is good to mention, too. Something like, here on the second line of first paragraph.

For example, the lack of use of Vue built-in directives in render functions forv-if and v-for as in template:

[hasssan]

Incorrect command in Guide: Coditional and Loops section:

"In the console, enter app3.todos.push({ text: 'New item' })"
should be:
"In the console, enter app4.todos.push({ text: 'New item' })"

[chrisvfritz]

@chay22 You're not missing anything - slots is indeed a function that returns a slots object within functional components. The docs have now been updated to reflect that. As for the directives, it's not _universally_ true no directives are allowed in render functions. For example, v-on has the on equivalent. It's really only when for directives or other Vue features that can be easily replaced with simple JavaScript.

@hasssan Thanks! Fixed the typo.

[jbruni]

@chrisvfritz @yyx990803

vm.$el documentation at https://github.com/vuejs/vuejs.org/blob/2.0/src/api/index.md#vmel

currently says

The DOM element that the Vue instance is managing. vm.$el will return a DOM element that created with the Vue instance.

The first sentence is ok. The second sentence needs to be rephrased.

(Sorry, I don't have a good suggestion. I would have made a PR if I had.)

Thank you.

[chrisvfritz]

@jbruni Thanks, fixed!

[chrisvfritz]

We're locking this thread for now, as the discussion part of the docs is pretty much done now. We still welcome continued feedback in the form of new issues though! 😃

[chrisvfritz]

The core docs are now officially complete! We'll continue to improve them, but everything should have basic coverage.