New RFC of defineEmits in vue 3.3 ?

[edwinhuish]

I saw this in twitter More ergonomic defineEmits() with types coming in 3.3!,

But... why we just do it like this:

const emit = defineEmits<{
     foo: (id: string) => any;
     bar: (...args: any[]) => any;
}>();

[yyx990803]

Because the return type is irrelevant in most cases. Why would you prefer a more verbose syntax?

[darrylnoakes]

Just an example of what I mean:

// PLAIN

type Line = {
  type: "line"
  value: string
}

type Section = {
  type: "section"
  value: Line[]
}

// WITH HELPER

type Node<T extends string, V> = {
  type: T
  value: V
}

type Line = Node<"line", string>
type Section = Node<"section", Line[]>

All I've done is abstract away the common syntax.
Which would you choose?

[edwinhuish]

Your demo is wrong.

Your code is normal ts generics type, it makes sence.

If vue strong enough to invent a new script type like "VueScript", it's very good news, you can invet everythings you want for "VueScript", because it's NOT javascript or typescript. Otherwise, I think it's better to follow the javascript/typescript rules.

Same question for you, which do you prefer? Shorter typing or variable name with meaning & IDE helper?

[darrylnoakes]

It is following "TS rules": it's a normal generic type.

But, instead of specifying full function types, you only need to specify the name and arguments for each ([id: string] is the parameters for a function of the form (id: string) => any).

[jacekkarczmarczyk]

Same question for you, which do you prefer? Shorter typing or variable name with meaning & IDE helper?

In the RFC you have names with meaning and IDE support, AND it's short.
If you're objetion is that the generic type you provide to defineEmits is not really the type of the actual emit function then neither is your proposal, you don't use it like emit.foo(arg1, arg2)

[darrylnoakes]

My 2 cents re verbosity: It's not so much about reducing typing or the number of characters, but allowing the developer to focus on what actually matters. The important information is the event name and the data it can have. The fact that it's a function isn't the point, nor is its return type, so why specify things that are irrelevant?

All you're talking about are the IDE's job. The code is not only for you to understand at that moment, but also for other collaborating programmers, even for your in the future.

So I should specify irrelevant info, just because my IDE can autocomplete it for me? Contrived extreme case: do you want me to write an extension that inserts a comment with a timestamp every time you create a new line?

[Demivan]

Example by @edwinhuish just makes sense. I can't explain why.
This was the syntax that I first tried with generic defineEmits, before failing and checking the docs.

Funny thing, this was just suggested to me by Copilot:

	const emit = defineEmits<{
		'update:modelValue': (value: boolean) => void
	}>()

[edwinhuish]

When in the component, definition as RFC:

const emit = defineEmits<{
  click: [value: boolean]
}>()

When we try to undenstand how it work:

emit('click', true)

The train of thought should be like follow:

const emit = (eventName, ...args) => {

  // HERE WILL RETURN A ARRAY AS DEFINITION.
  // WE DON'T UNDERSTAND WHY AND HOW IT GOING TO WORK.
  // THIS IS WHY I SAY "breaks away from the original semantics"
  const arr = $getEmitVal(eventName);
  // ....
}

[darrylnoakes]

The train of thought should be like follow:

const emit = (eventName, ...args) => {

  // HERE WILL RETURN A ARRAY AS DEFINITION.
  // WE DON'T UNDERSTAND WHY AND HOW IT GOING TO WORK.
  // THIS IS WHY I SAY "breaks away from the original semantics"
  const arr = $getEmitVal(eventName);
  // ....
}

Why? It would be the same as you said originally:

const emit = (eventName, ...args) => {
  const callback = $getEmitCallback(eventName);
  if (callback) {
    callback(...args);
  }
}

The array type in the RFC is simply the parameter list of the event callback.

[darrylnoakes]

Why would anyone think they should pass an array?
Your examples make me think you are treating the type as the type of the callback.
The type is not the type of what must be bound.
Currently, the full generic type passed is the exact type of the emit function itself. With this RFC, it will instead be a map of event names to the data they have, with the data being in the form of a tuple (as used for parameter lists).

[edwinhuish]

I think you should ask someone who know typescript but never use vue before, and let him write the code whithout explain to him.

You will know what is "Keep It Simple and Stupid" mean.

[darrylnoakes]

Then they can use the original syntax; it's quite understandable, just rather verbose. What's the issue?

The original syntax is simply the type of the emits function. The new one is a map of event name to event data.
What's the advantage of your proposed syntax?

I see this:

type Original = {
  (e: NAME, DATA_ITEM) => any
  (e: NAME, ...args: DATA_LIST) => any
}

type RFC = {
  NAME: [DATA_ITEM]
  NAME: DATA_LIST
}

type Yours = {
     NAME: (DATA_ITEM) => any
     NAME: (...args: DATA_LIST) => any
}

I don't see why the proposed syntax doesn't make sense.