从HTML Components的衰落看Web Components的危机 about blog

[yyx990803]

1. Web Components 中 Custom Elements 规范里命名必须带一个短横 -，这基本上是起到强制命名空间的意义。链接

2. Shadow DOM 内的样式默认就是局部作用域的。链接

3. 通讯

   • 从内向外：就是沿用现有的 DOM 事件 API。
   • 从外向内：Polymer 的做法是通过暴露公开的属性 (attributes)，然后用 MutationObserver 来观察属性的变化，并且保持对应的 property 和 attribute 之间的同步。用法上是 <input type="xxx" value="xxx"> 这样的感觉。至于动态的数据，Web Components 规范本身其实不涉及数据的绑定和传递，具体实现还是由框架来执行。

4. 数据源问题，我觉得好像没什么特别难的，在一个闭包里定义共享的部分和构造函数即可。举个简单的例子：

   (function () {
     var sharedStore = new Store() // 共享的数据推送/抓取服务，可以包含缓存机制
     var customElementProto = Object.create(HTMLElement.prototype)
     customElementProto.createdCallback = function () {
       this.data = sharedStore.fetch() // 调用共享的数据
     }
     document.registerElement('my-element', {
       prototype: customElementProto
     })
   })()

5. 需要明确一点，那就是 Web Components 作为一套规范并不试图取代框架的职责，而只是提供一套和现有 DOM API 风格一致的封装机制。每个 component 内部可以采用不同的实现，但是不管你内部用什么框架，对外暴露的都是一样的 API。所以你可以在框架 A 写的应用里很轻松地使用内部由框架 B 实现的组件。这样组件复用的一大难题：框架不兼容的问题就被抹平了。个人认为，这才是 Web Components 的核心意义所在。对于框架作者来说，并不需要针对 Web Component 做出很大的调整，只需要提供一个注册用自身实现的 Web Component 的便利函数就足够了。

6. Polymer 和 Web Components 不是一回事，Web Components 是一套规范，Polymer 是一个框架。Polymer 本身也分三部分：

   1. 抹平浏览器差异，实现 Web Components 规范的 polyfill
   2. 核心框架。其实就是基于 DOM 对象本身的 MVVM，理念是 "DOM 就是 ViewModel"。
   3. 在核心框架基础上附加的组件系统。

   在核心框架的层面上，Polymer 和 Angular、React 虽然各自实现有很大的差异，但从功能的角度来看其实是差不多的。

[yyx990803]

删掉 shadow dom 代码的事情，是因为 google fork Blink 之后不再维护那部分了，Apple 的人又不想就着烂摊子继续写，所以就删了... 其实他们是想删了以后从头自己写，倒还真不是故意拆台。

[gideonstele]

发现了一个问题：

在我眼里，html/css/js 是用作排版布局的，是类似于 .doc 的东西；
在你眼里，html/css/js 是用作实现人机交互，甚至是实现业务本身的，是类似于 .exe 的东西...

可怜的html啊，能同时满足我们俩嘛...

[gideonstele]

我有一个奇葩的想法：把浏览器 javascript 各个模块做成类似java的package的机制，webcomponent、ES6标准全部变成一个js package集成在浏览器js引擎里，但默认不加载，代码用到时再import。

其实就是担心js变“重”，“doc”类的页面一般都要求“快”，“exe”相对这方面要求低一些。说不定随着网络和硬件的进化，这些担心都是多余的……

还是忍不住吐槽啊，内些为了做web app而产生的奇葩DOM结构、CSS Tricks、JS Tricks实在是不忍直视啊，会被逼疯的……

[markyun]

学习，国庆快乐。

[xufei]

如果是我来实现Web Components，很可能会以iframe为蓝本，删除作为独立页面所拥有的cookie，localStorage等东西，并且把跟主文档的关联适当删掉一些，然后，js部分真不知怎么搞了，那个公共的部分不知放哪好……

[LingyuCoder]

个人感觉Angular这样的框架主要是着重点在于MVVM的开发方式，而WC则着重于对html本身标签提供自定义的扩展方案，WC应当融入到MVVM的V层面，而VM和M层面的管理以及VM和V的双向绑定依旧交给Angular去做

[tiye]

我关于 React 跟 Web Compoennts 的对比主要基于 Pete Hunt 的说明 https://t.co/mY04yPZABR
Web Components 的做法问题在于依然用 DOM 操作为维护状态, React 的方式更好,
而数据绑定只是让操作的流程更方便, 并不是让调试变得轻松了.

虽然我们通常思考组件化都认为界面拆成一个个 Module, Module 之间通过事件相互通信
但是在 React 当中, 做法其实是写一个 state 的值, 通信在界面重绘过程中直接完成了
这种方式将 Message 隐藏在了流程内部, 因此程序员编写代码不再需要写消息状态维护的代码
Web Components 里沿用 DOM 的属性和事件, 与之相比差异非常大

以及 React 所属的函数式响应式编程一派的 Elm 对于界面的处理:
http://elm-lang.org/Examples.elm#intermediate
Elm 中有模块重用的概念, 可是编程的思路更是不一样
我没能掌握具体不好说, 但这些让我对 Web Components 那一套很有怀疑态度

说 Elm 有点跑题, 不过拿过来对比 HTML 这边, 看着确实这边的抽象有些问题..
http://debug.elm-lang.org/

Our debuggers are limited by our programming languages. In languages like C++, Java, and JavaScript, we step through stack traces because that is the most concise way to express the meaning of an imperative program. We step forward, one command at a time, mutating variables, writing to files, sending requests. These debuggers typically only go forward because each step may destroy past state. In short, low-level languages lead to low-level debuggers.

[liyinkan]

爪机码字还痛苦。弄到后来，除了布局，都朝着 .net 里客户端组件那样的封装发展着……

[jumbo]

@myst729 最新的测试版safari已经加了对shadow dom支持，开发工具已经可以展开input 内部了

[hax]

@xufei 公共部分的疑问其实已经有解决方案，就是 SharedWorker。
[更新] 又想了下，这个场景还是 @yyx990803 说的在createCallback中注入更适合。或者就是通过暴露自定义dom property来做（允许主文档指定不同的数据源）。还有一种可能的方式是用通过es6 module导入公共模块（前提是内部的loader是和主文档相同或衍生的）。

[hax]

namespace 那个我赞同。现在草案用短横线的方式是过犹不及的愚蠢方式。

[hax]

我个人对wc持保留意见，倒不是在这些方面，而是自定义标签太容易被滥用。看看polymer的例子，大部分都是实现ui，完全违背语义化。更不要说一个custom element内部的实现（当然作为内部实现，dirty通常是无所谓的）。当初 BECSS 没有进一步标准化，至少也有因此遭到反对的部分原因。

[cnberg]

求转发至 div.io ~

[cutewalker]

应该是“明日黄花” 哈

[catjam]

Polymer 群： 192188831

[myadomin]

我X 发现issue写blog太爽了

[xufei]

@ShiJinYu 这也就是我之前说，两帮不同目的的人，抢同一个平台标准的话语权，不仅仅在Web Components这块，还包括ES的语法，做应用的想一步到位搞成C＃那样，做页面的只愿接受ES3-ES5这种小幅更新。

所以我一直对标准推进速度挺悲观的，觉得这两派人要的不是同样的东西。上次 @yyx990803 也说了，Web的应用化是不可逆的潮流了，从Win32，Swing，WinForm，Flex这条路线上来的我当然乐于看到这条路线，但反对者肯定越来越多……

[stanleyxu2005]

很多时候一些技术落寞了，是受时代的局限，不能说那些技术本身不好。说不定html component的精髓会在不久的将来以另外一个形式回来。

[sapjax]

很明显不能放在组件内部了，只能放在某个“全局”的地方，但刚才我们假设的是，组件内部的JavaScript代码不能访问外界的对象，所以……
但要是让它能访问，组件的隔离机制等于白搭。最好的方式，也许是两种都支持，默认是局部作用域，另外专门有一个作用域放给JS框架之类的东西用，但浏览器实现的难度可能就大了不少。

组件的js本来就是全局的，你这假想一个敌人，然后来批判....

[steelli]

还是比较看好的

[qiangspecial]

个人认为 Web Component 和 react, angular此类框架关注的问题本身就不一样
Web Component 更关注于组件化,组件之间互不干扰
react,angular关心的是M与V的一致性

[lizheming]

所以总而言之就是博主觉得 Web Component 太组件化了，和主文档的事件交流和数据交流都很麻烦，是这个意思么？

[stanleyxu2005]

@lizheming 经典桌面应用时代，mfc或者vcl都是mvc分离的。组件的独立性非常强。也没有见到事件交流和数据交流有多复杂。以前web的很多控件能力不强，现在这方面的劣势已经没有了。只要用桌面应用的思路能玩转，其他的领域想必是可以推广出去的。

[lizheming]

@stanleyxu2005 别误解我只是看了博主的文章之后有点晕乎想要总结下文章的中心槽点，知道说什么之后才好正确判断这事... 我也没说我同意与不同意哈。

[tsoukw]

关于楼主提出的端到端组件第二个问题，即页面上的不同组件同步数据问题。
1.当前页面设计时，是如何看待这两个组件是否需要同步。
大部分时候是不会要求同步的。企业应用是多人协作，多人在不同地点操作同一数据。

可能系统管理员在维护职业列表，而开单的人用一个下拉列表框读取职业列表，这个时候就是两个完全不同的上下文，没有谁会要求这时候要同步数据，就算做得到，代价太大，发生的机率太小，也没必要。

如果删除了一个职业，用户选了提交会怎样，那是业务逻辑层管控的问题，它必然会检查某个职业是否还存在资料表中。

如果用户要选取管理员刚刚新增的那个职业（那一定是它刚才有联系管理员，要求他加的），这个时候最简单的方式（程式没有负担），用户关掉程式在打开。
或者程式准备一个刷新按钮，用户单击刷新一下（不过这个对于当前这个下拉框场景可能不实用）。
我们是将这个下拉框组件的每次下拉刷新属性设为true，这样用户再次单击一下下拉框，程式就会重新读取数据库，用户就可以选取到那个新职业了。

如果有人说用户修改了职业名称了，比如说警察修改成了护士，那用户明明看到的是警察，怎么提交后就变成了护士。这种情况确实奇葩，问题本质上是那位管理员的作法，一般会将警察修改成警察(Police)，但很少会将警察变成护士这种业务上有问题的东西，因为这个table作为外键关联表，很多现在存在的数据的意义都会改变，所以还要具体场景具体分析（例如将id和名称同时带入，在服务端一起验证）

先写这些，起床了~~

[xufei]

@tsoukw 传统的企业系统确实是不需要主动同步，但我们注意到，近几年的很多系统都偏向单页化，相对注重体验了。一个单页化的应用，最重要的是变化是几乎没有“刷新”操作，所以可以看到很多这方面的探索，比如有的产品不再直接使用HTTP做通信，而是把全部业务操作都封装成某种协议，经过WebSocket进行通信。

目前来看，对于较大型的产品，业务比较复杂，做这方面的事情难度会比较高，但是如果追求极致的用户体验，这个事情是值得去探索的。

比如刚才那个职业名称列表，为什么就不能是服务端进行一个“推送”？

[tsoukw]

2.有的时候确实要同步
例如我们导航菜单组件里的菜单项有个star的图标，用户单击后就会将这个菜单项加成快捷方式。
另一个显示快捷方式的组件在导航菜单下的页面主要区域。
当然在导航组件中单击某个菜单项加入快捷方式后，快捷方式组件能够立刻响应，看到刚刚加的快捷方式已新增进来了。

这个时候涉及到的就是同步问题，首先找到导航菜单组件和快捷方式组件的共同父组件，由那个父组件（就是拼装两个组件）来实现同步。导航菜单组件在加入快捷方式成功后，发送事件给父组件，父组件调用快捷方式组件的刷新方法重新载入数据。
这是最简单的方式，避免了复杂的数据同步问题。

那还有一种是重复取数据导致的浪费问题，导航菜单组件实际上也是由多个子菜单组件组成，每个子菜单组件都要一份相同的【我的快捷方式数据】，以便在某个菜单项上显示star图标，表示这个菜单已加入快捷方式。像这样的子菜单组件，每一个都是动态载入，也不知道谁会先载入，谁会后载入，但是每个子菜单组件在自己内部都会去请求【我的快捷方式数据】，这样不仅浪费网络，也浪费内存，所以需要想办法来共用。

这种问题涉及到了组件的本质问题，到底要怎样封装一个组件？
端到端组件的本质又是什么？

UI组件本质上只包含两个部分：view,data
比如那个菜单组件的view就是一行行的div(菜单项)根据MENU数据（用于显示菜单名称在div里）以及我的快捷方式数据（用于某个div是否加上s-fav-menu的class）
这就够了，这就是业务组件
那我们请求MENU数据的逻辑和请求我的快捷方式数据的逻辑就不需要在那个组件里了吗？
如果不加入这部分逻辑，显然这个组件离封装差太远了，如果加上，又会造成请求逻辑和数据浪费的问题，两难。

其实请求逻辑是业务组件的外围，能够自己在组件内部就去完成所有数据的请求逻辑最好，但本质上它们是两个互相独立的概念。业务组件只要数据就可以完成组件渲染，数据如何来，从何处来是进一步封装的问题。默认情况下当然封装在一起，这也利于我们分而治之独立开发调试。但我们因为认识到它是外围概念，所以知道它和组件本质实际上可以分离。

在需要控制它的业务数据请求逻辑时，就可以控制（例如提供一个disableGetFavMenuData属性，如果为true，则自己不去请求）,父组件停用子组件的请求后，自己去抓取相关的业务数据，并把它直接赋值给各个需要的子组件。

最近在网上看到楼主很多文章，和楼主一样，做这些事情好多年了，有空可以多多交流~~

[tsoukw]

@xufei 没错，如果确实要同步，就只能通过这种推送作业。

像一些面向个人的产品，如todo-list这种，在一个终端改了数据，在另一个终端如果立刻显示出来，那带给用户的体验肯定是满满幸福感的。像支付宝付钱，网页显示二维码，手机扫后，网页就知道了，马上显示付款成功。这种感觉真是太棒了，赞一个支付宝团队。

[xufei]

@tsoukw 是的，数据和组件层是需要分开设计，然后在整体方案上加以整合的。最近几年业界很多话题，有不少是跟这层东西相关的，大型应用最复杂的东西并不在上层组件的切分，而是数据和业务逻辑层的设计，以及他们与上层组件的通讯方式。

[tsoukw]

@xufei 大型UI，不应该是横向划分成MV*，而是应该将切成多个子组件，子组件又划分成子组件，分而治之。每个子组件可以独立运行，又可以灵活地组装，这样才有机会保证大型UI的稳定和成功。

当到最低一层的原子组件时，会发现，所有的MV_都失去了意义，直接控制view和同步数据是一件简单又高效地做法，因为view和data都足够少，MV_要解决的问题都已不再是问题。所以研究组件可能比研究MV*更应该成为UI未来的方向

[yurychika]

@myst729 公司内部去dojo非常厉害 其实现在反过来看 dijit这一套东西出来得那么早 即使现在看他得一些理念还是相当厉害 就像你说的 SPA 即使用dijit也完全没问题

[stanleyxu2005]

@tsoukw 组件本身也是符合mvc的....
大型项目按照模块划分，我的理解是把单层次的mvc，演变成了多层次的mvc来管理。
打碎细分后的业务逻辑能重用的部分，就可以定义成组件了。
我们说的组件分两类：(1)原生通用的 (2)业务逻辑发展出来的。

[showzyl]

但有些事情我直到后来很久以后才想明白，基于业务的端到端组件虽然写起来很方便，却是有致命缺陷的。@xufei

致命缺陷是啥啊？

[Kpyu]

大大文章开头有个成语用错了，是明日黄花😂

[pengcc]

看到评论里有提到style，最近看了一些css in js， https://vimeo.com/116209150 , https://speakerdeck.com/vjeux/react-css-in-js， 请教各位高手，对这样的技术什么态度？