Version

3.2.23

Reproduction link

sfc.vuejs.org/

Steps to reproduce

See the link above

What is expected?

User should be able to use _createElementVNode as it's desired variable name or compiler should give out an error during compile.

What is actually happening?

Runtime gives out an error says _createElementVNode is not a function

Who really needs it? I think it's meaningless, this is not worth the effort🤔

As Vue continues to develop, it might accidently take over what users used as their variable names and then break things.

What's more, users have the right to use anything they want as their variable names, at least get a warning if accidently encountered one built-in keyword that might break things.

We could indeed warn during compilation so the user is aware they need to change the name of the variable

Ideally we should rewrite conflicted identifiers to unique ones, as our internal identifiers may change over time thus accidentally break user code which used to work. But I think the chance of conflicts are quite low ATM.

I think that's why they are all prepended with _: to avoid conflicts with user-defined properties. But yeah, they could be rewritten too

Oh, sorry, my first impression is that someone intentionally rewrite builded api. But the focus is how to avoid conflicts, it does make sense. I came up with some ideas:

• If user-defined properties start with a underscore, we can give the name suggestion. eg console.log( '...not recommend' ). This is the simplest solution, but it's too limited for user.
• Like @Justineo said, it really does work, but maybe cause too much work.
• A compromise would be to add prefix for user-defined properties during compile, eg __u_.

Also, see discussion for version 2: https://github.com/vuejs/vue/issues/5879

And, suggestion from @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 ¯_(ツ)_/¯

Read it and got the feeling that the babysitter just won't let you take your own sip of milk.

@ClassicOldSong are you a socialist?

@kospl No I'm not, but does it have anything to do with this issue?

@ClassicOldSong so what exactly you found offensive in referenced comment?

@kospl Vue takes user's freedom of using _ and $ as their variable prefix away since Vue2 and not doing a thing about it in Vue3, even removed the warning that was present in Vue2. Similar things are happening in Vue in multiple aspects such as the previous version of ref proposal, which was trying to modify the original meaning of : in JavaScript since "almost no one use it". I'm disappointed that @yyx990803 even blocked me on multiple platforms discussing the ref problem.

I don't want to expand this problem to something personal, but babysitting is considered harmful to powreusers.

@kospl To be clear, I'm not refering to that specific comment but the fact that the whole discussion didn't make any change to Vue.

@ClassicOldSong yeah, just try to be a professional, and polite when you discuss anything in public repository. We all can't agree with everything, but it's not a reason to offence or bully people on the internet.

@kospl I tried, but you'll feel the same when you're getting trapped everywhere by the babysitter, talking to it but it teased you with not skilled and taped your mouth.

I'm really not saying that anyone should offence anyone discussing a problem on the public internet, but I was the first to be offenced by a word of not skilled from the author of Vue.