建议添加一个组件：菜单项

[yetrun]

This function solves the problem (这个功能解决的问题)

目前菜单组件需要通过传递 options 构建菜单项，这种写法并不友好，出于以下几点考虑：

1. 不像表格，构建菜单不是操作数据，它更适合用 v-for 之类的模板语法基于模板构建；
2. 不像表格，菜单项无法保证总是一致类型的数据，可参考浏览器的菜单构造；
3. 在 <script> 标签下编写大量的模板语言（如 h 函数、jsx）视觉上就不太友好。

针对第 2 点，可以再解释一下。比如我有几个菜单项：

• 第一个菜单打开一个文件；
• 第二个菜单跳转一个路由；
• 第三个菜单跳转到一个外部页面；
• 第四个菜单执行一个动作，比如显示一个对话框。

这种情况下用 NMenu 组件再传递 options 就很不舒服，不单单是 render 函数的问题，而是这里处理这些菜单的回调很是麻烦。

针对第 3 点，可以说是最吐槽的地方了，不得不在 <script> 标签里编写很多行代码的视图层结构。但大部分组件本不需要这样的，它们毕竟不像表格组件那样需要传递一致结构的数据。

Expected API (期望的 API)

添加一个菜单项组件，如 NMenuItem，然后像下面这样在模板里构建即好：

<n-menu>
  <n-menu-item @click="doOne">菜单一</n-menu-item>
  <n-menu-item @click="doTwo">菜单二</n-menu-item>
  <n-menu-item @click="doThree">菜单三</n-menu-item>
</n-menu>

即使是一致类型的数据，用模板构建也不麻烦：

<n-menu>
  <n-menu-item v-for="option in options" :key="option.value" @click="handle(option.value)">
    {{ option.label }}
  </n-menu-item>
</n-menu>

[07akioni]

不会考虑。

这中间不光涉及到使用成本。还有开发成本、维护成本、渲染性能、对 A11Y 的支持难度。

除了特定情况下的使用成本外，剩下的所有条件 slot 都完败，综合考虑才用的 options。

PS：为什么说是特定条件下的使用成本呢，比如 options 是从后端传过来的、或者在编写模板时候不能确定的情况下，options 都是更好的选择。

[fudiwei]

毛遂自荐 @skit/x.naive-ui，基于 Naive-UI 二次封装了 Menu 等组件，支持模板中定义 options：

<x-n-menu>
  <x-n-menu-item v-for="option in options" :key="option.value" @click="handle(option.value)">
    {{ option.label }}
  </x-n-menu-item>
</x-n-menu>