javascript - 如何组织 Javascript UI？

Question

我需要有关程序架构的良好示例和最佳实践。

我正在尝试为与 Google.Maps 配合使用的应用程序构建 JS 用户界面。在第一稿中，用户应该能够以类似于 G.M. 的方式在 map 上绘制几何形状。然后通过 AJAX 发送形状并显示响应。

问题是代码因为多边形编辑而变得复杂。

受到 Joel 的“管道胶带程序员”的启发，我试图绘制一个简单的代码来生成操作和切换事件处理程序，以避免大的 if-else 树。 “新多边形”按钮为 map.onclick 创建一个观察者，更改其他按钮的事件处理程序或隐藏它们，并隐藏自身等。

这种方法的缺点是数据处理代码与接口(interface)混合在一起。创建一个 div 容器以在新多边形上显示数据的代码位于处理 w/G.M 或 w/形状数据的代码旁边。如果我想修改 UI，我将需要处理整个应用。

我可以稍后查看它并将这个 UI 生成代码移到别处，但后来我的首席程序员来了。相反，他坚持“消息传递”方法:一个简单的事件系统，其中对象订阅事件并触发它们。接口(interface)代码可以与数据处理和与 G.M 的对话完美隔离，但现在每个监听器都必须仔细检查此消息是否发给它。

例如，单击 map 上的多边形必须突出显示它并开始编辑。但如果正在绘制另一个多边形则不会。所以，一些“你在和我说话吗？”代码在任何地方都是必要的。

我会欣赏 UI 架构方法的好例子。

Answer 1

向您建议的事件处理思路是一个很好的方法。

这里还有一些想法:

• 把形状绘制的东西变成一个组件
• 形状绘制组件向其他代码发送事件，以对诸如“编辑”或“点击”之类的内容使用react
• 该组件还可以处理编辑部分 - 它向 Controller 发送“点击”事件， Controller 告诉组件进入编辑模式
• 在编辑模式下，组件在编辑结束前不会发送正常的“点击”事件，避免了必须检查的问题

一般来说，拥有一个“ View ”层是个好主意，它只处理显示数据并将有关用户对该数据的操作(即点击等)的事件发送到“ Controller ”层，然后决定做什么 - 例如，它可以决定将 View 更改为编辑模式。