当前位置:Gxlcms > JavaScript > 2018js回顾:框架存在的根本原因原来是这些

2018js回顾:框架存在的根本原因原来是这些

时间:2021-07-01 10:21:17 帮助过:19人阅读

现代 js 框架解决的主要问题是保持 UI 与状态同步。使用原生 JavaScript 编写复杂、高效而又易于维护的 UI 界面几乎是不可能的。我曾见过很多很多人盲目地使用(前端)框架,如 React,Angular 或 Vue 等等。这些框架提供了许多有意思的东西,然而通常人们(自以为)使用框架是因为:

  • 它们支持组件化;

  • 它们有强大的社区支持;

  • 它们有很多(基于框架的)第三方库来解决问题;

  • 它们有很多(很好的)第三方组件;

  • 它们有浏览器扩展工具来帮助调试;

  • 它们适合做单页应用。

但这些都不是使用框架的根本原因。

最最本质的原因是:

640?wx_fmt=png

(UI 与状态同步非常困难)

是的,就是这原因,让我们来看看为什么

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

640?wx_fmt=png

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

(你可能会说:)那又怎样?好吧,让我们看看如何在不用框架的情况下实现它:

用原生(JS)实现相对复杂的 UI

以下代码很好地说明了使用原生 JavaScript 实现一个相对复杂的 UI 所需的工作量,使用像 jQuery 这样经典的库也需要差不多的工作量。

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

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

640?wx_fmt=png

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

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

因此,保持 UI 与状态同步,需要编写大量乏味且非常脆弱的代码。

响应式 UI 拯救一切

640?wx_fmt=jpeg

所以,(之所以使用框架,)不是因为社区,不是因为工具,不是因为生态,不是因为第三方库......

目前为止,框架最大的改进是(为我们)提供了应用内部状态与 UI 同步的可靠保证。

只要你清楚特定框架的某些(特定)规则(如不可变状态),就差不多(可以正常使用)了。

我们只需要定义一次 UI 界面,不再需要为每个操作编写特定的 UI 代码,同时,每个相同的状态均有相同的输出(译者注:指 UI 一致):当状态改变后,框架自动更新(对应的)视图。

框架是如何工作的呢?

基于两个基本的策略:

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

  • 通过(添加)观察者监测变化,如 Angular 和 Vue.js。应用中状态的属性会被监测,当它们发生变化时,只有依赖了(发生变化)属性的 DOM 元素会被重新渲染。

那 Web components 呢?

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

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

自己动手,丰衣足食

如果热衷于了解底层原理,想知道虚拟 DOM 的具体实现。那,为何不试着在不使用框架的情况下,仅使用虚拟 DOM 来重写原生 UI 呢?

这里是框架的核心,所有组件的基础类。

640?wx_fmt=png

这里是重写后的 AddressList 组件(借助 babel 来支持 JSX 的转换)。

640?wx_fmt=png

现在 UI 是声明式的,我们并未使用任何框架。我们能任意添加新逻辑来改变状态的同时,不需要编写额外的代码来保持 UI 同步。问题解决了!

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

可以在这个 Github 仓库中找到完整的源代码。

结论

  • 现代 js 框架解决的主要问题是保持 UI 与状态同步。

  • 使用原生 JavaScript 编写复杂、高效而又易于维护的 UI 界面几乎是不可能的。

  • Web components 并未提供解决同步问题的方案。

  • 使用现有的虚拟 DOM 库去搭建自己的框架并不困难。但并不建议这么做!

相关推荐:

php ci框架中加载css和js文件失败的原因及解决方法

视频:前端JS开发27个经典实战视频教程

视频:JavaScript高级框架设计视频教程-免费在线视频教程

以上就是2018 js 回顾:框架存在的根本原因原来是这些的详细内容,更多请关注Gxl网其它相关文章!

人气教程排行