Menu 在openKeys受控状态下切换mode不正常

[wmzy]

Environment(required)

• antd version:2.7.1
• OS and its version:Fedora 24
• Browser and its version:Chrome 56.0.2924.87 (64-bit)

What did you do? Please provide steps to re-produce your problem.

0. 打开http://codepen.io/wmzy/pen/oBVbQO?editors=1010
1. 展开一个子菜单
2. 切换mode数次

What do you expected?

在vertical模式下子菜单不应该展开

What happen?

在vertical模式下子菜单展开了

Re-producible online demo

codepen

[benjycui]

Trace: #3783

所以 vertical 时弹出子菜单才是符合预期的行为。

问题在于，第一次切换时就应该弹出才对。

[afc163]

现在第一次切换也弹出了，如果希望切换后不弹出，在切换 mode 时使用 openKeys 进行精确控制。

[wmzy]

因为看到了这么一句话,以为你们就是这么设计的。
如果非inline模式也支持受控的话，openKeys state 和相应代码是不是就不需要了？{...this.props}不是直接透传了吗？

[afc163]

这是最新的代码，保留 openKeys 因为需要这个：

ant-design/components/menu/index.tsx

Lines 142 to 143 in e801cd0

	// There is this.state.openKeys for
	// closing vertical popup submenu after click it

另外，弹出型的菜单的受控模式没有使用场景

这句话已经在 #3783 修正掉了，现在都支持受控模式。

[wmzy]

明白你的意思，开始没有留意#3783.
请关注一下后一段：

如果非inline模式也支持受控的话，openKeys state 和相应代码是不是就不需要了？{...this.props}不是直接透传了吗？

这句和这句是不是不需要了?

[afc163]

我上面说了原因呀，注意链接里的注释。

[wmzy]

抱歉，刚才没看明白。
如果是出于这个目的, 受控模式下是不是应该在handleClick里面通过this.prop的onOpenChange([])来交给上层close？

[afc163]

这是交互需要，组件就默认实现了。

[nai6514531]

@afc163 现在第一次切换也弹出了，如果希望切换后不弹出，在切换 mode 时使用 openKeys 进行精确控制。那是在vertical时把openkeys设置成空数组吗？那样的话后续就不会渲染菜单了。怎样在vertical时做到对openkeys的精确控制呢？