评论菜单更新

一些FastComments租户自定义了评论小部件。这在您的自定义与我们的实现之间创建了一个契约。我们尽最大努力不破坏此契约，但作为此次公告的一部分，我们有一个小的破坏性更改。

评论菜单的CSS选择器已更改。

旧：

.comment .menu .menu-content

新：

.menu-content

如果您已经在使用“menu-content”选择器 - 恭喜您！我们已经检查了所有使用此选择器的租户，并更新了他们的小部件配置，以防止出现问题。

如有任何问题，请告诉我们。

自从创建评论小部件以来，评论菜单完全是一个由CSS驱动的下拉菜单。这是一种简单快速的实现下拉菜单的方法，而且不需要太多代码 - 这是FastComments的设计目标。

然而，多年来它出现了一些问题。

首先，当评论区域有特定高度且可滚动时，例如在流式聊天中，访问底部的菜单很困难，因为菜单会试图超出可滚动内容区域。这使得部分菜单不可见，并且需要您移动鼠标并重新悬停在菜单上，以完成您刚刚试图进行的工作。我们认为这让人使用起来感到沮丧。

曾经有一些变通方法，例如将菜单方向向上翻转，但如果小部件高度不够高且菜单中有很多操作项（例如对于管理员而言）时，这也不起作用。在这种情况下，理想的情况是在可滚动内容区域之外下拉菜单。

这个变化的一个好处是，我们能够将大量代码抽象为异步加载的模块。这将允许我们在不使小部件的初始加载变得臃肿的情况下，扩展您可以对评论数据采取的操作。这会在您第一次悬停在编辑菜单上时引入网络请求，但初始包非常小（< 1kb），因此这应该不会很明显。

继续发展软件并随时间减少其大小是非常困难的。通常，软件开始时快速而变得缓慢。因此，我们始终乐于努力让FastComments保持快速：

更改前：28.76kb gzipped（总计108.02kb）
更改后：28.39kb gzipped（总计105.79kb）

更少的代码意味着浏览器在页面加载时需要解析的代码也更少。随着更多功能的添加，这一点的影响将会扩大。

旧菜单渲染所有菜单项，并加载所有扩展以查看扩展是否有要添加的项，并为每个评论渲染这些内容，以便内容随时准备好供您的鼠标使用。

通常只有30 - 100个对象，因此这并不太重要，但影响在不断增加。新的系统消除了这个顾虑，菜单现在仅在需要时渲染。

权衡是新的菜单使用JS进行定位和渲染，以实现我们想要的效果。我们将继续进行优化，但目前它的表现良好。

感谢我们的客户耐心地实施这些更改。我们希望您继续喜爱FastComments。

干杯！