-
-
Notifications
You must be signed in to change notification settings - Fork 33.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Establish consistent naming convention for all hooks in Vue #3172
Comments
And actually, since the transition system's |
Good point, I think we should just take a pass at all hooks across different parts of the lib and ensure we have a consistent naming convention. |
A bit off-topic and far-stretched, but I've always been wondering about the convention of Vue's options as well, namely |
Sounds good. Here are the major patterns I think I'm seeing now:
@yyx990803 What do you think would be the best convention to settle on? For me, I think the 3rd option (which also seems to be what we've generally been moving towards) feels nicest. It may also be the only one that can fully accommodate every situation. And places where we have hooks (may not be exhaustive - it is almost midnight here 😉 ):
|
@phanan Good point. This could be a good time to also set explicit rules to follow for naming component options. Looking at the API, I think this might be the reverse-engineered rules I'm seeing:
Current exceptions:
|
To be fair, I'm not a big proponent of renaming things, unless there will be a warning for when you try to use an old-style name in 2.0. But warning should not pop up when you use an arbitrary name (in my case |
postupdate
to afterUpdate
?
Just did a more thorough evaluation of the current directive hooks, in the context of a more far-reaching campaign for consistency. Here are a couple areas for confusion I've noticed, with possible solutions at the end: 1. Confusions with what's being "updated"The directive interface's 2. Consistency with lifecycle verbsWithin the component lifecycle, the With those changes, we'd then have the concepts of create, update, and destroy mirrored in directives. Which leaves mount conspicuously missing, despite waiting for the element to be in the document being part of one common use case for directives (see below), among others: Vue.directive('focus', {
bind: function (el) {
Vue.nextTick(function () {
el.focus()
})
}
}) For convenience, it may be good to complete the set with a hook for mounting, so that the above can be simplified to something like: Vue.directive('focus', {
onMount: function (el) {
el.focus()
}
}) Possible solutionAssuming the prefix + verb infinitive pattern, these are some possibilities:
|
@simplesmiler I think you're right that arbitrary renames can be pretty annoying. We do want to be sure that anything we're renaming isn't just because a new name "feels" better, but actually makes Vue's API clearer and more intuitive. In the case of directives, since they work quite differently than they used to, changing all the hooks might actually alleviate confusion, because then users won't expect the same behavior as before. A few quite big changes: they take new arguments, no longer have instances, and As for the existing 1.x lifecycle methods that would change with a move to the prefix + verb infinitive pattern ( And the transition system in 2.0 already follows this pattern, so no changes would be necessary there. An advantage of consistent names, especially for new users, is that with a little experience they can probably guess the name of a hook and be right most of the time, whether it has to do with the component lifecycle, directives, transitions, or whatever else. That's why I think it might be worth it. |
I'm just worried that I'm be among the people who debug things for half an hour only to find that I did use an old name of the hook 😀 |
I'd like to avoid big naming changes for the sake of API continuity, so the goal is
What I see right now that feels inconsistent are:
I think if we fix these we could settle on the following:
Based on these rules, the changes would be:
|
Implemented in |
In lifecycle methods and the transition system,
before
/after
prefixes (with camelCase) seem preferred instead ofpre
/post
. For consistency and also because "before" and "after" are probably more accessible to Vue's non-native English speakers, perhapspostupdate
should be renamed toafterUpdate
.The text was updated successfully, but these errors were encountered: