Establish consistent naming convention for all hooks in Vue
See original GitHub issueIn lifecycle methods and the transition system, before
/after
prefixes (with camelCase) seem preferred instead of pre
/post
. For consistency and also because “before” and “after” are probably more accessible to Vue’s non-native English speakers, perhaps postupdate
should be renamed to afterUpdate
.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:7
- Comments:11 (11 by maintainers)
Top Results From Across the Web
12 VueJS Best Practices for Pro Developers - LearnVue
Another naming convention is focused around naming base components – or components that are purely presentational and help setup common styles ...
Read more >Style Guide - Vue.js
Prop names should always use camelCase during declaration, but kebab-case in templates and JSX. We're simply following the conventions of each language. Within ......
Read more >Introduction to Vue lifecycle hooks - LogRocket Blog
It is inside them that Vue components are created and exist, these functions are called lifecycle hooks. There are eight lifecycle methods:
Read more >VueJS component style guide | Codementor
Vue.js provides all Vue handler functions and expressions are strictly bound to the ViewModel. Each component events should follow a good naming ......
Read more >Create a Basic useFetch Hook in Vue.js | by Wendy de Kock
We start by creating our useFetch function, since it's a hook we'll start our function name with 'use' as convention dictates. Next, we...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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:
postupdate
hook in custom directivesonEnter
andonLeave
for transitionsI think if we fix these we could settle on the following:
bind
,update
,enter
): indicates the user is implementing this hook to perform the specified action.created
,mounted
): indicates the action was performed by the framework and the hook is exposed for its timing.beforeMount
,afterEnter
,enterCancelled
): also indicates the action was/will be performed by the framework and the hook is exposed for timing purposes.Based on these rules, the changes would be:
postupdate
->componentUpdated
onEnter
->enter
,onLeave
->leave
The reason I changed them to
onEnter
andonLeave
in the first place was due toappear
, which is a boolean, not a hook. However I think we can just determine the need for appearing transition simply by testing the presence ofappear
,afterApear
andbeforeAppear
, andappear
can either betrue
or an actual hook.Implemented in
next
branch.