Replies: 26 comments 44 replies
-
|
I believe, stopping to support old syntax by default could be the best. |
Beta Was this translation helpful? Give feedback.
-
|
I feel that abandoning Emit is still very good, Emit is a bit too complicated |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, i'm noob. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, the better replacement is mentioned in the post. |
Beta Was this translation helpful? Give feedback.
-
|
Haven't noticed about it. |
Beta Was this translation helpful? Give feedback.
-
How do I replace construction like @click="!disabled && $emit('click')"? |
Beta Was this translation helpful? Give feedback.
-
|
@daniluk4000 |
Beta Was this translation helpful? Give feedback.
-
|
I find myself comfortable with the logic of <script lang="ts" setup>
type Item = {
key: string,
title: string,
onClick?: () => void
}
defineProps<{
items: Item[],
current?: string,
}>();
defineEmits<{
(e: 'update:current', payload: string),
}>();
function handleClick(item: Item) {
emit('update:current', item.key)
item.onClick.?();
}
</script>
<template>
<nav>
<ol>
<li v-for="item in items" :key="item.key">
<button @click="handleClick(item)">{{ item.title }}</button>
</li>
</ol>
</nav>
</template> |
Beta Was this translation helpful? Give feedback.
-
|
@exodusanto If you feel comfortable using emits, keep using them, but do be careful of the potential costs as mentioned in the post. |
Beta Was this translation helpful? Give feedback.
-
|
Gotcha. |
Beta Was this translation helpful? Give feedback.
-
|
@exodusanto The benefits of all-in-props are mentioned in the post, making listeners required, etc. currently is just not possible with emits. Behind the scenes, |
Beta Was this translation helpful? Give feedback.
-
|
Passing callback in In event-based (current) approach component takes pure data as props and is only responsible for emitting events and doesn't care how the parent will handle it. So, from my perspective, in this example type Item = {
key: string,
title: string
}
defineProps<{
items: Item[],
current?: string,
}>();
defineEmits<{
(e: 'update:current', payload: string),
}>();
function handleClick(item: Item) {
emit('update:current', item.key)
} |
Beta Was this translation helpful? Give feedback.
-
Coud not agree more! |
Beta Was this translation helpful? Give feedback.
-
|
It depends. As a huge open-source framework, there are a lot of people who prefer these syntax sugars. It's an optional usage. |
Beta Was this translation helpful? Give feedback.
-
|
I don't really see how this is simpler I have a hard time understanding what you are actually doing. Is the idea that people pass a function into the component from the parent? I don't understand your example. Besides, I think deprecating emit and v-model is not a good idea. Think about all the code that is written like this. Way too much. |
Beta Was this translation helpful? Give feedback.
-
@tintin10q Yes. |
Beta Was this translation helpful? Give feedback.
-
But this is already possible right? If you want to write your components like that then go ahead but why deprecate other features? Also, even though I see how it can be nice I think that its conceptially more complicated to pass functions. I like the seperation between data : and events with @. |
Beta Was this translation helpful? Give feedback.
-
@tintin10q |
Beta Was this translation helpful? Give feedback.
-
|
Why not just use React and let Vue be like it is. I mean don't get me wrong but those sugar are essential things of Vue. two way binding, component emits. props vs emits: I think the sugar helps to simplify the understanding of wat a component do. Props are input events are output. Props vs v-model: we like that magic and now with defineModel is sweeter and more simple. The post of the creator of naive is right about ts issues with the current tooling but is more about someone missing react syntax. |
Beta Was this translation helpful? Give feedback.
-
Vue deserves to be saved.
Props in, UI's out is a simpler mental model.
Your favored magic is at the cost of much more complicated TypeScript integration and bad TypeScript DX. |
Beta Was this translation helpful? Give feedback.
-
|
@yyx990803 What's you take on this? |
Beta Was this translation helpful? Give feedback.
-
|
I'm confused; what about v-model modifiers like Or isn't this the |
Beta Was this translation helpful? Give feedback.
-
<!-- v-model.lazy -->
<comp :value="value" @change="value = $event" />
<!-- v-model.number -->
<comp :value="value" @input="value = +$event" />
<!-- v-model.trim -->
<comp :value="value" @input="value = $event.trim()" />@francoism90 If another dev needs to change this code, which format do you think is easier for them to debug, extend, and scale, the |
Beta Was this translation helpful? Give feedback.
-
|
@wenfangdu Maybe not a popular opinion, but I would use the VueJS has always been the more accessible and go to choice for beginners, I don't think this change would help the framework. A lot have still not moved to the new API, even though it offers more maintainable code. I'm also worried about all the tutorials out there using I also use alternative like Livewire, and they also use 'model' binding. Although not fully the same, the syntax is pretty easy to understand and the chances of an error using So yeah, I wouldn't deprecate both of them. Edit: I also use |
Beta Was this translation helpful? Give feedback.
-
|
I'm with "wenfangdu"
Only bootstrap-vue support lazy Please don't let this discussion go to waste keep it always on top of the discussion list to get Vue team's attention |
Beta Was this translation helpful? Give feedback.
-
|
I think best way is to remove/deprecate |
Beta Was this translation helpful? Give feedback.
-
|
I played around a little using props instead of emits, and didn't hit any roadblocks so far. The only problem right now is devtools support - you don't have Component events anymore. |
Beta Was this translation helpful? Give feedback.
-
|
The only idea here is to adopt a convention where all the handlers must be starting with 'on' 🧐 |
Beta Was this translation helpful? Give feedback.
-
|
@johannes-z Because there are no custom events, the |
Beta Was this translation helpful? Give feedback.
-
|
I know - I'm just saying the current tooling doesn't really support this; or in other words, it makes it harder tonsee if events are actually working. |
Beta Was this translation helpful? Give feedback.
-
|
I assume the point of events is to discourage any component from changing its parent's data (except explicitly with models). That's great conceptually. I think it could just be more concise and consistent: <script setup>
// reactive variant of https://vue-macros.sxzz.moe/macros/define-prop.html#johnson-s-edition
// inspired by https://vue-macros.sxzz.moe/features/export-props.html
let count = $prop(0)
let user = $prop<User>()
// reactive variant of defineModel({ local: true }) with default value
let modelValue = $model(0)
// reactive variant of defineModel("userModel")
let userModel = $model<User>()
// identical to https://vue-macros.sxzz.moe/macros/define-emit.html
let increment = $event()
let add = $event<[amount: number]>("incrementBy")
</script>@sxzz How do you decide which macros to make? I actually came here looking for the origin of |
Beta Was this translation helpful? Give feedback.
-
|
@texastoland Vue always encourages One-Way Data Flow, even if you use |
Beta Was this translation helpful? Give feedback.
-
This is incorrect. You can either search or ask AI why
They solve the problem of causing changes in other objects (parent components) without holding a reference to them (1-way). As you mentioned models and callbacks accomplish this too:
This is partially or mostly correct. Vue (especially Vapor eventually) can be used progressively like native elements. Think about an
Vapor is planned to be an internal non-breaking change according to his presentations. |
Beta Was this translation helpful? Give feedback.
-
@texastoland The data flow is one-way, for true two-way data flow binding, see https://svelte.dev/docs/element-directives#bind-property.
"Entities must not be multiplied beyond necessity."
There's no
Only a subset of features will be supported in the beginning. |
Beta Was this translation helpful? Give feedback.
-
They're DOM events:
The features are (supposedly) internal only not (breaking) API changes. |
Beta Was this translation helpful? Give feedback.
-
@texastoland Can you remove
That's funny, I said, "Only a subset of features will be supported in the beginning." now you're deliberately removing my context. |
Beta Was this translation helpful? Give feedback.
-
|
The current workaround is to add the following ESLint rules to ban {
"no-restricted-syntax": [
"error",
{
"message": "emit is not allowed, use props instead.",
"selector": "[name=emit]"
},
{
"message": "$emit is not allowed, use props instead.",
"selector": "[name=$emit]"
}
],
"vue/no-restricted-syntax": [
"error",
{
"message": "emit is not allowed, use props instead.",
"selector": "[name=emit]"
},
{
"message": "$emit is not allowed, use props instead.",
"selector": "[name=$emit]"
}
]
} |
Beta Was this translation helpful? Give feedback.
-
|
I think But <script setup>
const props = defineProps({
onOk: Function
})
const emit = defineEmits(['cancel'])
function handleOk () {
const fromParentValue = props.onOk('To parent')
alert(`Parent return value is "${fromParentValue}", USE PROP event support two-way value.`)
}
function handleCancel () {
emit('cancel', 'To parent')
alert('USE EMIT, only support child emit value to parent callback.')
}
</script>
<template>
<button @click="handleOk">Ok</button>
<button @click="handleCancel">Cancel</button>
</template>
|
Beta Was this translation helpful? Give feedback.
-
@gimjin Excellent for what? |
Beta Was this translation helpful? Give feedback.
-
|
Vue key Tips "The Progressive JavaScript Framework", Using tsx in vue is not a good idea, because the official focus is not here. You need to know v-model has helped us a lot. Option, Composition setup(), Composition <script setup> confusing already, used with tsx will become Cola + Mentos. Improvement needs to be measured against gains and losses, I think for convenience in tsx and removing the v-model attribute is wrong. |
Beta Was this translation helpful? Give feedback.
-
|
@gimjin Also, if Volar doesn't add |
Beta Was this translation helpful? Give feedback.
-
|
You are right, the Vue team is not yet perfect, because there are still many important things to do, such as language-tools issue has 156 issues. It's not that v-model is bad, but that it prompts an exception in tsx. If you want the best service, you should choose what they recommend. It's like going to KFC and not getting the best coffee. Good luck. |
Beta Was this translation helpful? Give feedback.
-
|
@gimjin That's actually very funny, I use templates mostly, I said especially for TSX, doesn't mean it's good for templates, |
Beta Was this translation helpful? Give feedback.
-
|
When I started with Vue few years ago it's actually the confusion caused by emit that made me switch to React for years, now I don't have problems with emit (although I prefer to avoid it) and find |
Beta Was this translation helpful? Give feedback.
-
|
@StitiFatah In the example I showed in the post, |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I know it's the same, but I don't see the point on "forcing" an "on X" event syntax just for the sake of using the @ shortcut especially if the goal is to remove magic and go away from the event emitting way of thought |
Beta Was this translation helpful? Give feedback.
-
|
@StitiFatah I never suggested forcing a |
Beta Was this translation helpful? Give feedback.
-
|
Emits' main architectural advantage is that they are fire-and-forget (like DOM events). One component should never need to know if its parent component handles the event or not; just like a component should not rely on whether its parent uses Converting all emits to props is also prone to boilerplate, either:
Also, emiting dynamic events (a rare need, indeed) is less convenient: this.$emit(`update:${key}`, value)versus this.$props[`onUpdate${capitalize(key)}`]?.(value) |
Beta Was this translation helpful? Give feedback.
-
|
@leopiccionia I'm curious, do you use TypeScript with Vue 3? |
Beta Was this translation helpful? Give feedback.
-
|
In some projects, yes. Volar provides type-checking and completion for emits. Here's a quick demo: |
Beta Was this translation helpful? Give feedback.
-
|
@leopiccionia If you use TS with Vue 3 on a daily basis, you'll know that neither of these options is correct:
If // 1. Can't specify if `@visible-change` is required.
// 2. Can't specify the return type of `@visible-change`.
defineEmits<{ visibleChange: [visible: boolean] }>() // Vue ^3.3 named tuple syntax
That's just bad code, I recommend reading Too DRY - The Grep Test. |
Beta Was this translation helpful? Give feedback.
-
|
Events are not designed to be a way to pass required callbacks or inject dependencies to your child component. Required event listeners are contrary to the whole spirit of events, that's letting the parent component decide how or whether to handle them. Events are a way to decouple parent and child implementations, not to couple them. An From the above, it can be concluded that one can't rely on the return value of an event handler to function properly; Vue correctly types event handlers as returning Events are not always the perfect abstraction, but they're not just the same as props starting with |
Beta Was this translation helpful? Give feedback.
-
|
@leopiccionia Popular Vue 3 UI libraries don't use emit in their component definitions. |
Beta Was this translation helpful? Give feedback.
-
|
我注意到在一些UI库中是不适用emits的。他们在props中定义emit事件，这些都是vue3比较流行的库, 例如：
我们确实应该考虑下emits的必要性了。 |
Beta Was this translation helpful? Give feedback.
-
Yes, in our code-base we're not using emits because they're not type-safe. Still have to deal with it in Vuetify tho, I think having events that may or may not be handled makes more sense for 3rd party libs. But I guess you can just have an optional prop for that. Also The only concern I have is that all those defineProps/defineEmits/defineModel doesn't seem to work with |
Beta Was this translation helpful? Give feedback.
-
|
@Maxim-Mazurok Thank you for sharing your experience, I fully understand your pain points. |
Beta Was this translation helpful? Give feedback.
-
|
@Maxim-Mazurok vue.d.ts import Vue from 'vue';
import type { JSX } from 'vue/jsx-runtime';
import type { VNode } from 'vue';
declare module 'vue' {
export type SlotType = Array<VNode | JSX.Element> | VNode | JSX.Element | string | null;
export type DefaultSlot = {
default?: () => SlotType;
};
export type SlotsWithDefault<P = unknown> = P & DefaultSlot;
export type PropsWithVSlots<S, P = unknown> = P & { vSlots?: S };
export type PropsWithVModel<M, P = unknown> = P & { vModel?: M };
}types.ts export type ComponentProps = PropsWithVModel<boolean | undefined, { }>;
export type ComponentSlots = SlotsWithDefault<{
one?: () => VNode;
two?: () => VNode;
}>;
export type ComponentProps = PropsWithVSlots<ComponentSlots, { }> |
Beta Was this translation helpful? Give feedback.
-
|
Svelte and Qwik both offer Two-way Binding, which helps users to simplify their usage. <script setup>
import { ref } from 'vue';
const value = ref('');
</script>
<template>
<input v-model="value">
<p>{{ value }}</p>
</template><script>
let value = '';
</script>
<input bind:value>
<p>{value}</p>import { component$, useSignal } from '@builder.io/qwik';
export const App = component$(() => {
const value = useSignal('');
return (
<>
<input bind:value={value} />
<p>{value}</p>
</>
);
}); |
Beta Was this translation helpful? Give feedback.
-
|
@Shyam-Chen Svelte and Qwik implemented |
Beta Was this translation helpful? Give feedback.
-
|
Totally agree 💯 Here is an example of how hard is it to handle <script setup lang="ts">
import type { CheckboxRootEmits, CheckboxRootProps } from 'radix-vue'
import { CheckboxIndicator, CheckboxRoot, useEmitAsProps } from 'radix-vue'
import { Check } from 'lucide-vue-next'
import { cn } from '@/lib/utils'
const props = defineProps<CheckboxRootProps>()
const emits = defineEmits<CheckboxRootEmits>()
const { class: className, ...restOfAttributes } = useAttrs()
const emitsAsProps = useEmitAsProps(emits)
</script>
<template>
<CheckboxRoot
v-bind="{ ...props, ...emitsAsProps, ...restOfAttributes }"
:class="
cn('peer h-4 w-4 shrink-0 rounded-sm border border-primary ring-offset-background focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-primary data-[state=checked]:text-primary-foreground', className ?? '')"
>
<CheckboxIndicator class="flex items-center justify-center text-current">
<Check class="h-4 w-4" />
</CheckboxIndicator>
</CheckboxRoot>
</template> |
Beta Was this translation helpful? Give feedback.
-
|
This shows that |
Beta Was this translation helpful? Give feedback.
-
|
I'm a fan of simply removing |
Beta Was this translation helpful? Give feedback.
-
|
with emits, devtools could track events, and it's single way, just like dom events. |
Beta Was this translation helpful? Give feedback.
-
|
Guys I think this part of the video demonstrates the problems with emits very well. |
Beta Was this translation helpful? Give feedback.
-
|
Is it possible if props.onXXX adapted to @update:xxx automatically? this deepens the magic |
Beta Was this translation helpful? Give feedback.
-
|
Vue is not yet ripe for tsx and full typing( Try this - https://vue-macros.dev/interactive/. I didn't use it because half of my team uses webstorm |
Beta Was this translation helpful? Give feedback.
-
Well, it was not designed to be. :)
In general, or when using JSX/TSX?
I object 😉: The Cost of Javascript Frameworks | Tim Kadlec. There's also the JS Framework Benchmark (I picked the highest performing React cases):
Overall, and especially with the incredible improvements in the latest versions, Vue is doing pretty well. At the least, compared to React. |
Beta Was this translation helpful? Give feedback.
-
Probably then it was not worth writing about the fact that typescript support was added. Also, some examples from the documentation are not typed properly. I think it’s not worth mentioning the mandatory maximum typing of modern web applications.
In general, we just have something to compare with. Templates were good in the days of JavaScript and they were quite easy to understand. I know a lot of guys who entered the industry thanks to templates)
If you looked at how the tested applications were written, they are far from real. I conducted my own tests in which everything is not so rosy))
@darryl_noakes Thank you for sharing your opinion! |
Beta Was this translation helpful? Give feedback.
-
|
After using Svelte 5 event/props model it, for me it was far more easer to work with compared to Vue. The big reason is consistency. You get what you define nothing more nothing less. In Vue case you have no way to know which events are required, which ones are optional, fallthrough attributes make it harder still. If you try to be more strict with Vue events do not bubble (except native ones) so in my opinion making them just functions would allow to reuse infra we already have for props: typesafety, spreading, simpler model without any major downsides. Of course ecosystem is very large at this point and moving everything would be hard, but with enough push and codemods it would be worth it. |
Beta Was this translation helpful? Give feedback.
and others
-
Currently, to define props and events, we've got
props,emits,defineProps,defineEmits, and a possibledefineModel, each of them has different syntaxes, doubled or even tripled when using TypeScript. Even as a Vue veteran, that's a lot to digest and remember, which deviates from Vue's design philosophy of being simple and beginner-friendly, as a long-time Vue user, I don't see Vue going in the right direction.Functionally, props can do all
emit+v-modelcan do but in a more explicit, less magical, and more type-friendly way. There were countless times that we rewrotev-modelto:prop+@eventbecauseemitandv-modelcould not meet the needs, e.g.To replace
emitwith props, in the child component, we use@event="onVisibleChange($event)"(notice, not@event="props.onVisibleChange($event)", since props can be used directly in the<template>) instead of@event="$emit('visibleChange', $event)".In the parent component,
<child @visible-change="visible = $event" />still works, since under the hood, it's compiled toonVisibleChange: ($event) => $setup.visible = $event.Too many options to achieve the same functional goal create code inconsistencies and unnecessary debates, increase the framework learning curve, and are a huge maintenance burden both for the framework maintainers and users e.g. tooling support, more unnecessary new concepts to learn, more ESLint rules need to be created and applied, etc.
emitandv-modelserved us well in Vue 2 with JavaScript, and we didn't need to write types for them, but when combining Vue 3 with TypeScript,emitandv-modelhave generated too many unnecessary complexities.Popular Vue 3 UI libraries don't use
emitin their component definitions.v-modelcausing type-checking blind spots.I realized this post is too ahead of time for some people, it's futile to convince them, therefore, I won't reply any longer.
Beta Was this translation helpful? Give feedback.
All reactions