We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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
Please describe what the rule should do:
Allows to choose order of computed properties which can be defined in several manners, such as:
return
computed: { messages () { return this.$store.state.user.messages } }
computed: { messages: { get () { return this.$store.state.user.messages }, set (newValue) { this.$store.commit('SET_USER_MESSAGES', newValue) } } }
mapState
mapGetters
computed: { ...mapGetters(['isAuthorized']), ...mapState({ userStatus: state => state.user.status }) }
Rule should add an opportunity to enforce the same code style by ordering these different definition types of computed properties in desired sequence.
What category should the rule belong to?
Provide 2-3 code examples that this rule should warn about:
order: ['mapGetters', 'mapState', 'getters/setters', 'normal']
// Bad. messages: { get () { return this.$store.state.user.messages }, set (newValue) { this.$store.commit('SET_USER_MESSAGES', newValue) } }, hideHeader () { return this.$route.meta.hideHeader }, ...mapGetters(['isAuthorized']), ...mapState({ userStatus: state => state.user.status, nextStep: state => state.user.next_step }), noAuthRequired () { return this.$route.meta.noAuthRequired }
// Good. ...mapGetters(['isAuthorized']), ...mapState({ userStatus: state => state.user.status, nextStep: state => state.user.next_step }), messages: { get () { return this.$store.state.user.messages }, set (newValue) { this.$store.commit('SET_USER_MESSAGES', newValue) } }, hideHeader () { return this.$route.meta.hideHeader }, noAuthRequired () { return this.$route.meta.noAuthRequired }
The text was updated successfully, but these errors were encountered:
order-in-computed
No branches or pull requests
Please describe what the rule should do:
Allows to choose order of computed properties which can be defined in several manners, such as:
return
expression likemapState
andmapGetters
helpers.Rule should add an opportunity to enforce the same code style by ordering these different definition types of computed properties in desired sequence.
What category should the rule belong to?
Provide 2-3 code examples that this rule should warn about:
order: ['mapGetters', 'mapState', 'getters/setters', 'normal']
passed as configuration.The text was updated successfully, but these errors were encountered: