adds tip to methods documentation about underscore and dollar prefixed namespace collisions with methods

[JustinBeaudry]

This PR is in reference to vuejs/vue#6312.

Please note that this PR also add .idea/ to gitignore.

[chrisvfritz]

@JustinBeaudry Btw, I'm leaning towards closing this in favor of the runtime error we're discussing in the other issue, possibly combined a recommended rule in eslint-plugin-vue. For less commonly encountered gotchas where we can provide a just-in-time warning, I prefer to leave it out of the docs to reduce cognitive overhead.

Thanks for bringing this up though! The conversation you started will lead to improved communication with users one way or another, even if it's not in the docs. 🙂

[JustinBeaudry]

@chrisvfritz I'm torn on this. Whilst I do agree that preventing cognitive overload with caveats and gotchas is important, this one is particularly nasty and could have many emergent properties and propagations of effect. The API docs feels like it should be the source of truth for this, even if the runtime warns in dev, and even if the eslint plugin helps prevent the issue. I defer to you on this, obviously, as I'm new to Vue.

[chrisvfritz]

@JustinBeaudry I can see where you're coming from and it's possible I'll change my mind later, but at least for now, I think the added cognitive load is probably more likely to prevent people from absorbing the more vital information. We can place enough detail in warnings to help people understand why the rule exists and what they can do as an alternative.

One other side note though, referencing a comment in the issue:

I think it's unreasonable to expect people to have to respect naming strategies for methods

I had the same initial feeling coming to Vue from React. But over time, this "limitation" became one of my favorite features, because it leads to much more readable components.

For example, I've seen React components passed this.props.todos, containing an array from an API, then that array is normalized into a new array in this.state.todos, and finally filtered in a this.todos method. There are no name conflicts due to the scoping, but I'd argue the conceptual conflicts are worse.

This kind of conceptually sloppy code isn't possible in Vue. You're forced to use a different name for each prop, datum, computed property, and method - so you have to really think about what each thing actually is. The prop might be called todosApiResponse, the datum todos, then the method (or more appropriately, computed property in Vue) filteredTodos. Now the component makes more sense. It tells a clear story.

Similarly with conventions around _ and $, when I see an _, I know it's internal to Vue. When I see a $, I know it's a Vue instance property from outside the component - either internal, or from a mixin/plugin. In the future, Symbols can prevent code conflicts by allowing naming conflicts, but I'm not convinced that's even a good idea.

[JustinBeaudry]

I can see where you're coming from and it's possible I'll change my mind later, but at least for now, I think the added cognitive load is probably more likely to prevent people from absorbing the more vital information. We can place enough detail in warnings to help people understand why the rule exists and what they can do as an alternative.

🙇

I had the same initial feeling coming to Vue from React. But over time, this "limitation" became one of my favorite features, because it leads to much more readable components.

I agree. The issue for me is not that props, methods, etc. share a namespace it's that they share a namespace with internal methods.

Similarly with conventions around _ and $, when I see an _, I know it's internal to Vue. When I see a $, I know it's a Vue instance property from outside the component - either internal, or from a mixin/plugin. In the future, Symbols can prevent code conflicts by allowing naming conflicts, but I'm not convinced that's even a good idea.

I think a convention is fine and it makes sense.

In the future, Symbols can prevent code conflicts by allowing naming conflicts, but I'm not convinced that's even a good idea.

With Symbols I think the goal of it should be to scope Vue's internal methods (leaving an open namespace), but not to scope out top-level properties (props, methods, etc.).