[Vue 3.0] Deprecation of Emit decorator

[kaorun343]

ref #352

History

• Proposed by Proposal: @Emit decorator #41
• Implemented via @Emit #44

Problem

First, this decorator's behavior is defined by this library itself.

I would like to keep this library easy to estimate those decorators' behavior. However, @Emit decorator has some unique behaviors, for instance, catch return value and arguments and emit them, treat with promise. On the contrary, these behaviors are easily implemented without using this decorator.

// Same line count do same thing
@Component
class MyComponent extends Vue {
  @Emit('change')
  handleChangeA() {
    return 'new value'
  }

  handleChangeB() {
    this.$emit('change', 'new value')
  }
}

Proposal

I'd like to deprecate @Emit decorator.
Then, developers will use this.$emit instead.

[scscgit]

To provide some feedback: is there no chance of reconsidering deprecating the unique behaviors instead of deprecating the entire decorator, and are you sure that $emit satisfies all relevant use-cases? For example, personally I don't like how we can't disable emitting the passed arguments if we already return something else (which bloats Vue devtools even if we don't consume them, and having unused parameters introduces code stability risks, reducing effect of linters), but it's definitely preferred to be able to strongly type the $emit function without code duplication (of passing params) and explicit hard-coding of kebab-cased name that's hard to refactor (though the lack of options like an update: prefix doesn't make it perfect; but this at least seems to be covered by @PropSync, which even https://github.com/nuxt-community/nuxt-property-decorator exports unlike @ModelSync or @VModel; and there are even some custom ideas like a typed $sync). I had hoped that our direction will be towards actually enforcing all emit calls to be made via something like @Emit methods (through static linters), so that all events can be known at compile time, enabling defensive programming and more self-documenting components (possibly even making some v-on parameters required). Using $emit directly goes even further away from TypeScript; though the Vue 3 already seems to support RFC vuejs/rfcs#16 (mentioned in vuejs/core#1553), so I'm wondering if this library doesn't intend to cover the same functionality using this decorator. For example, one relevant feature could be the validation like in https://v3.vuejs.org/guide/component-custom-events.html#event-names. In any case, I wonder if with this deprecation we'll lose the option of covering use-cases that we'll newly discover in the future; possibly as meta-annotations to avoid the growth of parameter list. That said, I think the preferable way would be to collect feedback from heavy users of this library who maintain the largest Vue projects; have any such users confirmed that this won't negatively impact code quality? (Though maybe this responsibility over de-duplication could be shifted in the future to a meta-framework like Nuxt and its modules.) Hopefully this perspective provides some value :)

[kaorun343]

@scscgit Thanks for you feedback and I apologize you to may late replay.

After I received your feedback, I was thinking about this plan. As this emit decorator seems to be widely used, I decided to keep this decorator and update for Vue 3. Of course, the new emits option will be supported.