fix(DropdownMenu/ContextMenu): improve generic types

[yassilah]

🔗 Linked issue

Resolves #2140

❓ Type of change

Implements same type inference as #2482

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[pkg-pr-new]

pnpm add https://pkg.pr.new/@nuxt/ui@2490

commit: 4a04950

[benjamincanac]

I just tried it but it doesn't seem the types are well resolved 🤔

[yassilah]

I think this is linked to what I had suggested for the CommandPalette here #2260 (comment)

If your items don't all have the icon property then it is expected for TS to warn you as you'd be trying to access a potentially non-existing property. It's possible to go around that in two different ways:

• wrap it inside a v-if="'icon' in item" and then it'd work and infer types correctly;
• turn the union into an intersection and then it'd work even without v-if

Should I go for the latter?

[benjamincanac]

Yes I think that would be the most convenient 😊

[benjamincanac]

@yassilah Trying to understand your last changes, why do we need to use this new intersection type for DropdownMenu and ContextMenu but don't need it in NavigationMenu? 🤔

My thought would be that the types are wrong in DropdownMenuContent and ContextMenuContent.

[yassilah]

So I decided to go for this "optional intersection" instead of just "intersection" for 2 reasons:

• i thought it kind of defeats the purpose of type-safety to say that items all have the same properties when we know they don't;
• there's also a scenario where two items have conflicting types for the same property such as [{ foo: 'foo' }, { foo: 2 }] which would, in the previous implementation result into having { foo: never };

So I think this new way of inferring the types is safer and handles conflicting types properly.

[benjamincanac]

Do types work for you in this PR? I no longer have autocomplete on slots nor slot props 🤔