现代 JS 框架存在的根本原因

  假设你正在设计这样一个 Web 应用:用户可以通过群发电子邮件来邀请其他人(参加某活动)。UX/UI 设计师设计如下:(在用户填写任何邮箱地址之前,)有一个空白状态,并为此添加一些帮助信息;(当用户填写邮箱之后,)展示邮箱的地址,每个地址的右侧均有一个按钮用于删除对应的地址。

  这个表单的状态,可以被设计为一个数组,里面包含若干对象,对象由邮箱地址和唯一标识组成。开始的时候,数组为空。当(用户)输入邮箱地址并按下回车键之后,往数组中添加一项并更新 UI。当用户点击删除按钮时,删除(数组中对应的)邮箱地址并更新 UI。你感觉到了吗?每当你改变状态时,你都需要更新 UI。

  在这个例子中,HTML 负责创建静态页面,Java 通过 document.动态改变(DOM 结构)。这引来了第一个问题:构建 UI 相关的 Java 代码并不直观易读,我们将 UI 构建分为了两部分(译者注:应该是指 HTML与 Java 两部分)。尽管我们使用了 innerHTML,可读性是增强了,但降低了(页面的)性能,同时可能存在 CSRF 漏洞。我们也可以使用模板引擎,但如果是大面积地修改 DOM,会面临两个问题:效率不高与需要重新绑定事件处理器。

  但这也不是(不使用框架的)最大问题。最大的问题是每当状态发生改变时都要(手动)更新 UI。每次状态更新时,都需要很多代码来改变 UI。当添加电子邮件地址时,只需要两行代码来更新状态,但要十三行代码更新 UI。(此例中)我们已经让 UI (界面与逻辑)尽可能简单了!!

  代码既难写又难理解,更麻烦的是它非常脆弱。假设我们需要(添加)同步服务器数据到邮件地址列表的功能,我们需要对比服务器返回结果与数组中数据的差异。这涉及对比所有数据的标识与内容,(当用户修改后,)可能需要在内存中保留一份标识相同但内容不同的数据。

  为了高效地改变 DOM,我们需要编写大量点对点(译者注:指状态到 UI)的代码。但只要你犯下了很小的错误,UI 与状态将不再保持同步:(可能会出现)丢失或呈现错误的信息、不再响应用户的操作,更糟糕的是触发了错误的动作(如点了删除按钮后删除了非对应的一项)。

  重新渲染整个组件,如React。当组件中的状态发生改变时,在内存中计算出(新的)DOM 结构后与已有的 DOM 结构进行对比。实际上,这是非常昂贵的。因而采取(将真实 DOM)映射为虚拟 DOM ,通过对比状态变化前后虚拟 DOM 的不同,计算出变化后再改变真实 DOM 结构。这个过程称为调和(reconciliation)。

  很多时候,人们会把 React、 Angular 和 Vue.js (等框架)与 Web components 进行对比。这显然体现了人们并不理解这些框架所提供的最大好处:保持 UI 与状态同步。Web components 并不提供这种同步机制。它仅仅提供了一个template标签,但它不提供任何(状态与 UI 之间的)协调机制。如果你在应用中使用 Web components 时,想保持 UI 与内部状态同步,则需要(开发者)手工完成,或者使用如Stencil.js(内部和 React一样,使用虚拟 DOM)之类的库。

  让我们明确一点:框架表现出的巨大潜力并不体现在组件化上,保持 UI 与状态同步才是具体的体现。Web components 并未提供相关的功能,你必须手工或使用第三方库去解决(同步的)问题。使用原生 Java 去编写复杂、高效且易于维护的 UI 界面基本上是不可能的。这就是你需要使用现代 Java 框架的根本原因。

  现在,除了事件处理之外,这看起来就像个 React 应用对吧?我们有haverender()、componentDidMount()、setState()等等。一旦解决了保持应用内 UI 与状态的同步问题,所有东西就会很自然地叠加起来(形成组件)。

相关阅读