组件设计

第 61 篇原创好文～本文首发于政采云前端团队博客：如何开发跨框架的组件背景题主所在的业务中台团队，须要提供业务组件给不同的下层业务方应用，但因为一些历史遗留问题，不同业务线应用的框架不对立，包含 jQuery、React 、Vue 。为了满足不同业务方的需要，往往须要依据业务方应用的框架，开发对应框架的组件。 这样做就会产生一些痛点： 每种选型都须要开发一次，费时劳力组件降级，须要业务方同步发版降级，沟通老本高、迭代效率低现实中的组件跨框架：Write once, run everywhere少降级：组件降级，业务方少降级不降级（留神：组件降级后业务线回归还是必要的）实现计划如何设计一个合乎下面跨框架、少降级冀望的通用计划呢？ 很容易想到用原生 JS 来实现，防止跨框架的问题 原生实现用原生 JS 实现，蕴含页面里用到的 UI 组件，不依赖任何框架。 长处： 跨框架：不依赖于框架实现轻量：能够不依赖其余 UI 组件，体积较小毛病： 投入产出比低：实现一套常用工具办法和 UI 组件，投入工夫长踩坑：兼容性问题的坑要走一遍，危险大很难满足简单业务场景的需要实用场景： 不须要简单交互的场景，如前台吊顶、后盾菜单侧边栏可采纳这种形式。 但在理论的业务场景中，业务组件中有比拟多简单的交互场景， 下面的计划不太能满足要求，所以咱们在下面的计划之上进行迭代： 原生容器组件 + iframe 加载业务逻辑组件咱们将业务组件拆分为两局部 一、容器组件： 用原生 JS 实现中间层容器组件，解决跨框架的加载问题，容器组件次要负责： 收集组件须要的参数注册全局回调组件挂载加载 iframe二、业务逻辑组件 依据 iframe 人造的沙箱个性，业务逻辑用 iframe 页面加载，就保障了业务组件的实现不受框架的限度，能够完满解决问题。业务逻辑组件次要负责： 与容器组件通信运行环境隔离，能够应用任意框架实现业务逻辑毛病： 动静加载动态资源，iframe 加载略慢，理论体验在承受范畴内跨域通信问题此计划容器组件作为中间层，封装不变的逻辑，将多变的业务逻辑隔离进去，从而保障合作方尽量少降级或不降级。业务定制性可依据接口配置，返回不同的 iframe 地址，加载不同的业务逻辑组件，一次开发任意应用。 如何实现上面是整个组件的逻辑图 应用方通过容器组件初始化参数、并注册相应的回调： 容器组件 初始化： 设置 document.domain，让内部组件和 iframe 能够通信// 获取主域名function getTopLevelDomain(host) {    let data = host || window.location.host;    return data.split('.').slice(-2).join('.');}// 设置主域名function setDomainToTopLevelDomain() {  try {    window.document.domain = getTopLevelDomain();  } catch (error) {    console.error("设置domain失败")  }}render： ...