please unreserve underscore, and allow it for user usage

[xlotlu]

Version

2.3.4

---

I have been a developer for many years, and I, as many others, have been using underscore-starting variables and functions to convey special meaning: this is somehow restricted / it's temporary / it's for internal use / it's the real implementation and the other one is a wrapper etc.

Taking away this ability is unnecessary, it is handicapping developers, and opens the door for bugs. I was bitten by Vue's handling of _ properties a long time ago and had to do the same googling many others have done before me. But what prompted me to submit this issue is I just created a _render method: given that I was renaming a method that was already used in a few places, combine this with some other edits before and after the rename, the outcome was, as you can imagine, a long and frustrating session of debugging.

I propose underscore should be cleared for regular usage by users. This could be really simple, like renaming the internal stuff to start with $_ instead, or namespacing everything under something like this.$ (but I presume that would require some serious code shuffling).

[nickmessing]

Properties prefixed by _ and $ are historically used internally by vue. I don't think there is enough reasoning to change that.

[LinusBorg]

I don't think that it makes much sense to define methods, computed props etc in components as "internal" by using an underscore or any other convention, because generally, all of them should be considered internal - the public API of a component is defined by its props and events.

While you can access methods or data of a component programmatically through e.g. a $ref, that's something that's rarely happening and should be considered an edge case.

[posva]

accessing methods does happen but trying to hide properties from the user by just prepending _ or $ is an illusion

[xlotlu]

Yes, _ and $ are used internally, but there's a huge difference between them: $ provides a useful, documented, public API, while _ provides bug-prone unexpected behaviour.

(Yes, it's true the unexpected part is "somewhat documented", but nobody tells you "no, really, don't use underscores for anything, unless you like pain.")

My argument is simple, and frankly seems very compelling to me as a newcomer:

• _ is bug-prone. People will shoot themselves in the foot due to the unexpected behaviour. There's many issues in this here tracker proving that. (though I think my _render()-related experience is the worst yet).
• seasoned developers love _. Don't alienate them.
• _ is unnecessary. Getting rid of it is one simple search & replace away.

[yyx990803]

This is unlikely to happen because this will certainly break someone's existing code, and the gain is arguable.

What we can do is raise warnings when users declare data/props/computed/methods that start with _. I'd be open to a PR for that.

[Flamenco]

I am probably going to get an ass whippin' for suggesting this, but I would like to see a refactoring of __ and $$ instead of _ and $ internally in the next major version of Vue. Sure they are ugly, but they are internal and I won't have to see them.

Two very common javascript conventions reserved internally? That does not seem to have been the best choice.

I can live with losing the '$', but not the _ . Perhaps consider converting the internal '_' to '$$' or '__'.?

IDK ¯_(ツ)_/¯

[douglasg14b]

This naming reservation is a pain when using languages like TypeScript where the common syntax for a member variable backing getters/setters starts with an underscore.

This just sounds like Vue getting in the way of common conventions that have been around far longer than itself...

@Flamenco makes a good point in that Two very common javascript conventions reserved internally? That does not seem to have been the best choice.

[jartaud]

I just learn that the hard way.

[vertic4l]

Another reason why Vue just sucks :D

[xlotlu]

Another reason why Vue just sucks :D

@vertic4l, c'mon, that is neither helpful nor accurate.

Vue is a beautiful piece of engineering, with a few shortcomings. Which is to be expected, everything has shortcomings.

What's unconstructive though (and if there's something that qualifies for the expression you used I'd say this is it) is the attitude "if I don't find it helpful, then it can't be to others".

Pair that with logic of the sort "this is internal and undocumented so don't use it, but we can't change it because someone might rely on it.", and you have a recipe for frustration.

Projects that care about their users don't mind re-architecting, and have a deprecation strategy such that they warn clients of their API of oncoming changes. But then, that's not to be found here.

[timbyu]

As was stated many professional developers have come to use _ (underscore) as a prefix for special cases (Even the developers of Vue found it useful for their purposes!) It is one of two non alpha characters that can be used to start a variable name, $ being the other and is also take by Vue!

A simple case to demonstrate is to have a prop of something like "searchTerm". In order to do a .sync I will often have a local variable that receives that props value and then will emit the value as the local variable changes. Since "searchTerm" is a good descriptive name for the prop and since I can't reuse that name for my local variable I need a prefix. _ is a simple perfect match. "_searchTerm" is easy to recognize as being related to searchTerm and makes my code readable. Again, the underlying language does not allow for other single prefix characters and Vue is taking away the one that should be available. On the Vue side, simply changing the reserved _ (underscore) to __ (double underscore) would still be simple, concise and not collide with THE SINGLE REMAINING PREFIX WE HAVE AVAILABLE TO US. Vue 3.0 would be a good place to give underscore back the people (us developers)

[douglasg14b]

Really just needs another open issue at this point, because the decision to maintain this is some serious quality oversight...

Reserving a common convention for the language, so you can no longer use that convention...

[StrangeWill]

What would be handy: if we declare variables with underscores warnings get thrown.

Had some people on my team caught with this, it isn't immediately intuitive and nothing gives feedback as this being inappropriate (vue-cli, eslint, etc.), I get the reasoning but it would be good to provide a bit better feedback for the developer against this behavior when defining variables we expect to show up under this._thing don't.

[9mm]

@vertic4l not what you suck

[9mm]

Whatever you say Mr. Lindner

[vertic4l]

You know that this is against law and can be charged in real Life?