客户端应用程序的全局可变状态

Question

这可能是一个非常通用的（也许是天真的）问题。

据我所知，“客户端”应用程序（即在浏览器中运行的应用程序）的编程模型意味着有一个共享的可变对象 - 网页的DOM - 要更新由javascript程序。 天真应用我所看到的由几十个JS回调是更新一个大的共享DOM，

它是正确的吗？现代JS框架如何管理它？他们如何实现数据隐藏？

Answer 1

除非您依赖于window.open，iframe或允许您的应用程序跨越多个相互通信的窗口/选项卡（可能通过postMessage进行通信），否则您没有其他选择来操作同一文档：只有一个文档。

但是，这不是因为单个文档被操纵，文档本身不能被分成多个封装的协作模块。 Nicholas Zakas在他的演讲中很好地揭示了这个概念。

应该给模块一个非常严格的文档部分。这是他们自己的小沙箱，他们不应该到达其他模块的沙箱。如果他们需要沟通，他们会以非常分离的方式进行沟通（例如通过Mediator）。

大多数今天的框架都依赖于模型 - 视图 - 控制器（MVC）的客户端变体，通常称为MV */MVW来实现该目标。我不会在这里详细讨论，但主要目标是将数据从视图（表示）中分离出来，并且通常将视图与在Controller对象中完成的用户操作的处理分开。

直到最近，还没有真正的方法来执行封装。例如，不可能阻止某个jQuery插件外部的代码修改该插件生成的DOM结构。我们必须依靠程序员的专业知识来确保他们没有涉及到插件的内部。

现在，随着引入新概念（如Shadow DOM）的Web Components规范，真正的封装将能够发生。不幸的是，该规范尚未在浏览器中实现，但幸运的是，Google的Polymer项目可以被看作Web组件垫片。

Answer 2

现代JS框架使用JavaScript语言：在DOM事件

1. 寄存器兴趣
2. 响应DOM事件：通过创建或突变对象状态
   • 直接或
   • 通过制作远程“阿贾克斯”请求并使用响应更新其状态
3. 通过（有选择地）更新DOM来反映它们的部分或全部修改状态。

而那就是它。这就是现代客户端应用程序的基本运行循环。

有许多框架可以用来做到这一点，当然每个框架都以不同的方式实现基本范例。像jQuery这样的框架倾向于采用“DOM是真相”的方法，并将其状态数据从DOM中挂起，而其他像Ember.js的则处于另一端，并采用“模型就是事实”的方法，并在DOM。

许多框架中使用的常见模式是MV *，即Model/View/Something。框架将具有某种模型来管理状态，某种视图/模板层以及其他控制/协调/协调应用程序的功能。这可能是特定于不存在的（即数百个DOM事件回调），或者依赖于框架的结构和复杂性。

由于存在一些误导性评论，值得一提的是这些框架中的视图层不等同于DOM。 DOM中最终实际上是呈现视图的输出，即DOM是的视图的视图。