Replies: 0 comments 7 replies
-
Are |
Beta Was this translation helpful? Give feedback.
-
they are through $attrs like today in Vue 2. |
Beta Was this translation helpful? Give feedback.
-
Hi! Any feedback on this issue? I have some components that are basically just registries with some logic and I would love to be able to just use |
Beta Was this translation helpful? Give feedback.
-
How would type checking work in the templates if it's using attrs instead
of props
…On Tue, Jun 9, 2020, 8:28 PM PrettyWood ***@***.***> wrote:
Hi! Any feedback on this issue? I have some components that are basically
just registries with some logic and I would love to be able to just use
props in setup instead of duplicating the props option everywhere
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<vuejs/core#1155 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAKROQKCKLMUOXRVWGJVJDRVZWLDANCNFSM4M5GK5ZA>
.
|
Beta Was this translation helpful? Give feedback.
-
This is actually close to what Optional Props Declaration is, and has the same problem when dealing with attrs fallthrough:
Essentially, if we expose I notice you are using Another issue here is that in the current implementation, In this case, I also don't really see a reason to not use the To solve that, we may need to introduce a separate option, e.g.
|
Beta Was this translation helpful? Give feedback.
-
not in runtime, compile to "props" by loader instead, is it better? export interface PropsType {
title: string;
}
let ShorterWay = defineComponent<PropsType>((props) => {
return () => (
<p>{props.title}</p>
)
})
// compile to
export interface PropsType {
title: string;
}
let longWay = defineComponent({
props: {
title:String,
},
setup: (props) => {
return () => (
<p>{props.title}</p>
)
}
}) |
Beta Was this translation helpful? Give feedback.
-
defineComponent({
props: {
title:{
type: String,
required: true,
},
},
setup: (props) => {
return () => (
<p>{props.title}</p>
)
}
}) code like above is tedious. I think this is better: defineComponent<{title:string, subTitle?: string}>({
props: ['title', 'subTitle'], // this is to tell the difference between props and attrs
setup: (props) => {
return () => (
<p>{props.title} <span>{props.subTitle}</span></p>
)
}
}) |
Beta Was this translation helpful? Give feedback.
-
What problem does this feature solve?
context.attrs
This is defined in RFC 31. 2. In that case,setup()
's first argument,props
, is an empty object. This is not explicitly defined in the RFC above, but can be kind of expected.defineComponent
allows us to pass specific types forprops
through the first generic argument, but we can't set specific types forcontext.attrs
- it's always a plainData
type unless I manually typecast it insetup
, which I find to be less than ideal.Example:
What does the proposed API look like?
We have two possible solutions here:
props:
options are specified, theprops
argument contains all of the attributes, which means it contains the same content asattrs
.defineComponent
in a way that we can type attrs like we can now type props.I personally prefer the first way - if no
props:
options are defined, all attrs are also possibly props at the same time, so to me it makes sense that both contain the same references.Beta Was this translation helpful? Give feedback.
All reactions