「微前端」- 将微服务理念扩展到前端开发(实战篇)

前言与大纲

本文分为理论和实战上下两篇。本篇为微前端的实战篇,共计约 5k 字,预计阅读时间 10 mins。

技术雷达之「微前端」- 将微服务理念扩展到前端开发(上:理论篇)中,我们介绍了微前端在单体应用和微服务的架构演进中所产生的缘由,将微服务理念运用到前端开发就是为了解决臃肿前端的当前现状。与此同时,合理拆分微前端也给我们的应用开发带来显而易见的好处,在本篇当中我们将逐一介绍微前端的实践方案与可能遇到的问题和对应的优化建议。

文章大纲

  • 微前端的可选实践方案(4 种 +)
    • 创建更小的 Apps(而不是 Components)
    • 如何组合微前端的 App 模块?
      • Option 1: 使用后端模板引擎插入 HTML
        • Option 1.1: 渐进式从后端进行加载
      • Option 2: 使用 IFrame 隔离运行时
      • Option 3: 客户端 JavaScript 异步加载
      • Option 4: WebComponents 整合所有功能模块
    • 不同 App 模块之间如何交互?
    • More Options…
  • 微前端的页面优化与实例
    • 多模块页面加载问题与优化建议
    • 微前端在 AEM(CMS)项目的应用
    • 现成解决方案:Single-SPA “meta framework”
  • 总结与思考:微前端的优缺点
    • 微前端的优点
    • 微前端的缺点
    • 持续思考…
  • 附:参考资料

微前端的可选实践方案(4 种+)

创建更小的 Apps(而不是 Components)

首先让我们来创建一个典型 Web 应用程序的基本组件(Header、ProductList、ShoppingCart),以 Header 组件为例:

# src/App.js
export default () =>
  <header>
    <h1>Logo</h1>
    <nav>
      <ul>
        <li>About</li>
        <li>Contact</li>
      </ul>
    </nav>
  </header>;

然后需要注意的是我们会用到 Express 对刚刚创建的 React 组件进行服务器端渲染,使之成为一个 App 模块:

# server.js
fs.readFile(htmlPath, 'utf8', (err, html) => {
  const rootElem = '<div id="root">';
  const renderedApp = renderToString(React.createElement(App, null));

  res.send(html.replace(rootElem, rootElem + renderedApp));
});

再依次创建其他 Apps 并独立部署:

如何组合微前端的 App 模块?

在每个独立团队创建好各自的 App 模块后,我们就可以将网站或 Web 应用程序视为由各种模块的功能组合。下文将介绍多种技术实践方案来重新组合这些模块(有时作为页面,有时作为组件),而前端(不管是不是 SPA)将只需要负责路由器(Router)如何选择和决定要导入哪些模块,从而为最终用户提供一致性的用户体验。

Option 1: 使用后端模板引擎插入 HTML

# server.js
Promise.all([
    getContents('https://microfrontends-header.herokuapp.com/'),
    getContents('https://microfrontends-products-list.herokuapp.com/'),
    getContents('https://microfrontends-cart.herokuapp.com/')
  ]).then(responses =>
    res.render('index', { header: responses[0], productsList: responses[1], cart: responses[2] })
  ).catch(error =>
    res.send(error.message)
  )
);
# views/index.ejs
  <head>
    <meta charset="utf-8">
    <title>Microfrontends Homepage</title>
  </head>
  <body>
    <%- header %>
    <%- productsList %>
    <%- cart %>
  </body>

但是,这种方案也存在弊端,即某些 App 模块可能会需要相对较长的加载时间,而在前端整个页面的渲染却要取决于最慢的那个模块。

比如说,可能 Header 模块的加载速度要比其他部分快得多,而 ProductList 则因为需要获取更多 API 数据而需要更多时间。通常情况下我们希望尽快将网页显示给用户,而在这种情况下后台加载时间就会变得更长。

Option 1.1: 渐进式从后端进行加载

当然,我们也可以通过修改一些后端代码来渐进式地(Progressive)往前端发送 HTML,但与此同时却徒增了后端复杂度,并且又将前端的渲染控制权交回了后端服务器。而且我们的优化也取决于每个模块加载的速度,若是进行优化就必须按一定顺序进行加载。

Option 2: 使用 IFrame 隔离运行时

<body>
  <iframe width="100%" height="200" src="https://microfrontends-header.herokuapp.com/"></iframe>
  <iframe width="100%" height="200" src="https://microfrontends-products-list.herokuapp.com/"></iframe>
  <iframe width="100%" height="200" src="https://microfrontends-cart.herokuapp.com/"></iframe>
</body>

我们也可以将每个子应用程序嵌入到各自的 <iframe> 中,这使得每个模块能够使用任何他们需要的框架,而无需与其他团队协调工具和依赖关系,依然可以借助于一些库或者 Window.postMessageAPI 来进行交互。

  • 优点
    • 最强大的是隔离了组件和应用程序部分的运行时环境,因此每个模块都可以独立开发,并且可以与其他部分的技术无关
    • 可以各自使用完全不同的前端框架,可以在 React 中开发一部分,在 Angular 中开发一部分,然后使用原生 JavaScript 开发其他部分或任何其他技术。
    • 只要每个 iframe 来自同一个来源,消息传递也就相当直接和强大。参考文档 Window.postMessageAPI
  • 缺点
    • Bundle 的大小非常明显,因为可能最终会多次发送相同的库,并且由于应用程序是分开的,所以在构建时也不能提取公共依赖关系。
    • 至于浏览器的支持,基本上不可能嵌套两层以上的 iframe(parent - > iframe - > iframe)。
  • 如果任何嵌套的框架需要能够滚动或具有 Form 表单域,那样的情况处理起来就会变得特别痛苦。Option 3: 客户端 JavaScript 异步加载
function loadPage (element) {
  [].forEach.call(element.querySelectorAll('script'), function (nonExecutableScript) {
    var script = document.createElement("script");
    script.setAttribute("src", nonExecutableScript.src);
    script.setAttribute("type", "text/javascript");
    element.appendChild(script);
  });
}

document.querySelectorAll('.load-app').forEach(loadPage);
<div class="load-app" data-url="header"></div>
<div class="load-app" data-url="products-list"></div>
<div class="load-app" data-url="cart"></div>

简单来说,这种方式就是在客户端浏览器通过 Ajax 加载应用程序,然后将不同模块的内容插入到对应的 div 中,而且还必须手动克隆每个 script 的标记才能使其工作。

需要注意的是,为了避免 Javascript 和 CSS 加载顺序的问题,建议将其修改成类似于 Facebook bigpipe 的解决方案,返回一个 JSON 对象 { html: ..., css: [...], js: [...] } 再进行加载顺序的控制。

Option 4: WebComponents 整合所有功能模块

Web Components 是一个 Web 标准,所以像 Angular、React/Preact、Vue 或 Hyperapp 这样的主流 JavaScript 框架都支持它们。你可以将 Web Components 视为使用开放 Web 技术创建的可重用的用户界面小部件,也许会是 Web 组件化的未来。

Web Components 由以下四种技术组成(尽管每种技术都可以独立使用):

  • 自定义元素(Custom Elements)对外提供组件的标签,实现自定义标签:可以创建自己的自定义 HTML 标签和元素。每个元素可以有自己的脚本和 CSS 样式。还包括生命周期回调,它们允许我们定义正在加载的组件特定行为。
  • HTML 模板(HTML <template>定义组件的 HTML 模板能力:一种用于保存客户端内容的机制,该内容在页面加载时不被渲染,但可以在运行时使用 JavaScript 进行实例化。可以将一个模板视为正在被存储以供随后在文档中使用的一个内容片段。
  • 影子 DOM(Shadow DOM)封装组件的内部结构,并且保持其独立性:允许我们在 Web 组件中封装 JavaScript,CSS 和 HTML。在组件内部时,这些东西与主文档的 DOM 分离。
  • HTML 导入(HTML Imports)解决组件组合和依赖加载:在微前端的上下文中,可以是包含我们要使用的组件在服务器上的远程位置。
# src/index.js
class Header extends HTMLElement {
  attachedCallback() {
    ReactDOM.render(<App />, this.createShadowRoot());
  }
}
document.registerElement('microfrontends-header', Header);
<body>
    <microfrontends-header></microfrontends-header>
    <microfrontends-products-list></microfrontends-products-list>
    <microfrontends-cart></microfrontends-cart>
</body>

在微前端的实践当中:

  • 每个团队使用各自的技术栈创建他们的组件,并把它包装到自定义元素(Custom Element)中(如 <microfrontends-header></microfrontends-header>)。
  • Web 组件就是应用程序中包含的组件的本地实现,如菜单,表单,日期选择器等。每个组件都是独立开发的,主应用程序项目利用它们组装成最终的应用程序。
  • 特定元素(标签名称,属性和事件)的 DOM 规范还可以充当跨团队之间的契约或公共 API。
  • 创建可被导入到 Web 应用程序中的可重用组件,它们就像可以导入任何网页的用户界面小部件。
<link rel="import" href="/components/microfrontends/header.html">
<link rel="import" href="/components/microfrontends/products-list.html">
<link rel="import" href="/components/microfrontends/cart.html">
  • 优点
    • 代码的可读性变得非常清晰,组件资源内部高内聚,组件资源由自身加载控制,作用域独立。
    • 功能团队可以使用组件及其功能,而不必知道实现,他们只需要能够与 HTML DOM 进行交互。
    • 使用 PubSub 机制,组件可以发布消息,其他组件可以订阅特定的主题。幸运的是浏览器内置了这个功能。比如购物车可以在 window 订阅此事件并在应该刷新其数据时得到通知。
  • 缺点
    • 可惜的是,Web 组件规范跟服务器渲染无关。没有 JavaScript,就没有所谓的自定义元素。
      • 浏览器和框架的支持不够,需要更多的 polyfills 从而影响到用户页面的加载体验。
      • 我们需要在整个 Web 应用程序上做出改变,把它们全部转换成 Web Components。
      • 社区不够活跃,Web Components 还没有真正流行起来,也许永远也不会。

不同 App 模块之间如何交互?

# angularComponent.ts
const event = new CustomEvent('addToCart', { detail: item });
window.dispatchEvent(event);
# reactComponent.js
componentDidMount() {
  window.addEventListener('addToCart', (event) => {
    this.setState({ products: [...this.state.products, event.detail] });
  }, false);
}
  • 得益于浏览器的原生 API,Custom Event 可以与其他任何技术和框架一起工作。比如,我们可以将消息从 Angular 组件发送到 React 组件。其实这也是现在 API 之间普遍使用 JSON 进行通信的原因,即使没有人使用 NodeJS 作为服务器端。
  • 但是,新的问题又出现了。我们该如何测试这种跨模块之间的交互?需要编写类似于后端微服务之间的 Contract Testing 或 Integration Testing 吗?并没有答案。

More Options…

  • 组件库 – 根据主 App 的技术栈,不同的组件和 App 模块拆分作为库的形式提供给主App,所以主 App 是由不同组件组成的。但是组件库的升级将成为一个大麻烦,比如对 Header 组件进行了更改,那么如果已经有 50 个页面使用了 Header 组件该怎么办?必须要求每一页都升级它的 Header,而且升级过程中用户还会在整个网站不同页面上看到不一致的标题。并且,在两边还必须都使用相同的技术,比如 Header 组件中使用了 ClojureScript,而 Content 组件中又用了 Elm,那么该怎么办?构建工具就必须在编译时处理不同的语言。
  • 将 App 模块作为 React 黑盒组件分发给消费者模块 – 应用程序的状态完全包含在组件中,API 只是通过 props 暴露出来。这种方式其实增加了应用程序之间的耦合,因为它迫使每个人都使用 React,甚至会使用相同版本的 React,但是这似乎也是一个比较好的折衷。
  • Edge Side Includes(ESI)/Server Side Includes(SSI) – 通过特殊的文件后缀 (shtml,inc) 或简单的标记语言来对那些可以加速和不能加速的网页中的内容片断进行描述,将每个网页划分成不同的小部分分别赋予不同的缓存控制策略。SSI / ESI 方法的缺点是,最慢的片段决定了整个页面的响应时间。

微前端的页面优化与实例

多模块页面加载问题与优化建议

  • 使用 skeleton screen 响应式布局:如上图 LinkedIn 所做的那样,首先展现给用户一个页面的空白版本,然后在这个页面中逐渐加载和填充相应的信息。否则中间的信息流部分的内容最初是空白的,然后在 JavaScript 被加载和执行过后,信息流就会因为需要占用更多的空间而推动整个页面的布局。虽然我们可以控制页面来固定中间部分的高度,但在响应式网站上,确定一个确切的高度往往很难,而且不同的屏幕尺寸可能会有所不同。但更重要的问题是,这种高度尺寸的约定会让不同团队之间产生紧密的联系,从而违背了微前端的初衷。
  • 使用浏览器异步加载加快初始渲染:对于加载成本高且难以缓存的碎片,将其从初始渲染中排除是一个好主意。比如说 LinkedIn 首页的信息流就是一个很好的例子。
  • 共享 UI 组件库保证视觉体验一致:在前端设计中,必须向用户呈现外观和感觉一致的用户界面。建议可以建立一个共享组件库(包含 CSS、字体和 JavaScript)。将这些资源托管在 CDN,每个微前端就可以在其 HTML 输出中引用它们的位置。每个组件库的版本都正确地对资源进行版本控制,而每个微前端都指定要使用的组件库的版本和显式更新依赖关系。
  • 使用集中式服务(Router)来管理 URL:可以理解为前端的 Gateway,不同的 URL 对应不同应用程序所包含的内容。建议通过一个集中式的 URLs Router 来为应用程序提供一个 API 来注册他们自己的 URL,Router 将会位于 Web 应用程序的前面,根据不同的用户请求指向不同的 App 模块组合。
  • 提取共同依赖作为 externals 加载:虽然说不同 App 模块之间不能直接共享相同的第三方模块,当我们依然可以将常用的依赖比如 lodashmoment.js等公共库,或者跨多个团队共同使用的 reactreact-dom。通过 Webpack 等构建工具就可以把打包的时候将这些共同模块排除掉,而只需要在 HTML <header> 中的 <script>中直接通过 CDN 加载 externals 依赖。
<script
  src="https://cdnjs.cloudflare.com/ajax/libs/react/16.2.0/react.min.js"
  crossorigin="anonymous"></script>
<script
  src="https://cdnjs.cloudflare.com/ajax/libs/react/16.2.0/react-dom.min.js"
  crossorigin="anonymous"></script>

微前端在 AEM(CMS)项目的应用

我们在「三靠谱」(已和谐客户名称)的 Marketplace 项目当中也曾经探索过 AEM + React 混合开发的解决方案,其中就涉及到如何在 AEM 当中嵌入 React 组件,甚至将 AEM 组件又强行转化为 React 组件进行嵌套。现在回过头来其实也算是微前端的一种实践:

  • AEM 仅仅包含网页内容,不包含 domain 相关的结构化数据。
  • React 组件被托管在 AEM 组件当中,再经由 AEM 传递给组件所需要的属性,比如 IDs 或 APIs 的 URL 等等
  • 后端微服务则包含 domain 结构化数据,由对应的 React 组件通过 Ajax 进行数据查询。
  <div id="cms-container-1">
    <div id="react-input-container"></div>
    <script>
      ReactDOM.render(React.createElement(Input, { ...injectProps }), document.getElementById('react-input-container'));
    </script>
  </div>
  <div id="cms-container-2">
    <div id="react-button-container"></div>
    <script>
      ReactDOM.render(React.createElement(Button, {}), document.getElementById('react-button-container'));
    </script>
  </div>

现成解决方案:Single-SPA “meta framework”

开源的 single-spa 自称为「元框架」,可以实现在一个页面将多个不同的框架整合,甚至在切换的时候都不需要刷新页面(支持 React、Vue、Angular 1、Angular 2、Ember 等等):

  • Build micro frontends that coexist and can each be written with their own framework.
  • Use multiple frameworks on the same page without refreshing the page (React, AngularJS, Angular, Ember, or whatever you’re using)
  • Write code using a new framework, without rewriting your existing app
  • Lazy load code for improved initial load time.
  • Hot reload entire chunks of your overall application (instead of individual files).

请看示例代码,所提供的 API 非常简单:

import * as singleSpa from 'single-spa';

const appName = 'app1';

const loadingFunction = () => import('./app1/app1.js');
const activityFunction = location => location.hash.startsWith('#/app1');

singleSpa.declareChildApplication(appName, loadingFunction, activityFunction);
singleSpa.start();
# single-spa-examples.js

declareChildApplication('navbar', () => import('./navbar/navbar.app.js'), () => true);
declareChildApplication('home', () => import('./home/home.app.js'), () => location.hash === "" || location.hash === "#");
declareChildApplication('angular1', () => import('./angular1/angular1.app.js'), hashPrefix('/angular1'));
declareChildApplication('react', () => import('./react/react.app.js'), hashPrefix('/react'));
declareChildApplication('angular2', () => import('./angular2/angular2.app.js'), hashPrefix('/angular2'));
declareChildApplication('vue', () => import('src/vue/vue.app.js'), hashPrefix('/vue'));
declareChildApplication('svelte', () => import('src/svelte/svelte.app.js'), hashPrefix('/svelte'));
declareChildApplication('preact', () => import('src/preact/preact.app.js'), hashPrefix('/preact'));
declareChildApplication('iframe-vanilla-js', () => import('src/vanillajs/vanilla.app.js'), hashPrefix('/vanilla'));
declareChildApplication('inferno', () => import('src/inferno/inferno.app.js'), hashPrefix('/inferno'));
declareChildApplication('ember', () => loadEmberApp("ember-app", '/build/ember-app/assets/ember-app.js', '/build/ember-app/assets/vendor.js'), hashPrefix('/ember'));

start();

值得一提的是,single-spa 已经进入到最新一期技术雷达的评估阶段。这意味着 single-spa 会是值得研究一番的技术,以确认它将对你产生何种影响,你应该投入一些精力来确定它是否会对你所在的组织产生影响。

摘自技术雷达:

SINGLE-SPA是一个 JavaScript 元框架,它允许我们使用不同的框架构建微前端,而这些框架可以共存于单个应用中。一般来说,我们不建议在单个应用中使用多个框架,但有时却不得不这么做。例如当你在开发遗留系统时,你希望使用现有框架的新版本或完全不同的框架来开发新功能,single-spa 就能派上用场了。鉴于很多 JavaScript框架 都昙花一现,我们需要一个解决方案来应对未来框架的变化,以及在不影响整个应用的前提下进行局部尝试。在这个方向上,single-spa 是一个不错的开始。

总结与思考:微前端的优缺点

微前端的优点

  • 敏捷性 – 独立开发和更快的部署周期:
    • 开发团队可以选择自己的技术并及时更新技术栈。
    • 一旦完成其中一项就可以部署,而不必等待所有事情完毕。
  • 降低错误和回归问题的风险,相互之间的依赖性急剧下降。
  • 更简单快捷的测试,每一个小的变化不必再触碰整个应用程序。
  • 更快交付客户价值,有助于持续集成、持续部署以及持续交付。
  • 维护和 bugfix 非常简单,每个团队都熟悉所维护特定的区域。

微前端的缺点

  • 开发与部署环境分离
    • 本地需要一个更为复杂的开发环境。
    • 每个 App 模块有一个孤立的部署周期。
    • 最终应用程序需要在同一个孤立的环境中运行。
  • 复杂的集成
    • 需要考虑隔离 JS,避免 CSS 冲突,并考虑按需加载资源
    • 处理数据获取并考虑用户的初始化加载状态
    • 如何有效测试,微前端模块之间的 Contract Testing?
  • 第三方模块重叠
    • 依赖冗余增加了管理的复杂性
    • 在团队之间共享公共资源的机制
  • 影响最终用户的体验
    • 初始 Loading 时间可能会增加
    • HTML 会需要服务器端的渲染

持续思考…

  • 变幻莫测)前端的技术选型?
    • 前端 JavaScript 框架工具穷出不穷,过几个月就要重写前端项目?比如最近又出来了声称要取代 Webpack(Parcel)和 Yarn(Turbo)的工具。伴随着前端框架的更新换代,如果整个项目一起升级/重构的话压力大、风险高,那不如拆分微前端直接支持多 framework,或者同一 framework 的不同版本?`
  • 在 Mobile/Mobile Web 上的悖论
    • 受限于 Mobile 尺寸大小,单一页面所能展现的内容本就有限。
    • 既然已经分出了不同的子页面,那何不如直接 Route 即可?
  • 合理划分的边界:DDD(领域驱动开发)
    • 最大的挑战是搞清楚如何合理拆分应用程序。
    • 糟糕的设计可能成为开发和维护的噩梦。
  • Don’t use any of this if you don’t need it
    • Do not use the ideas described here until it is needed, it will make things more complex.
    • If you are in a big company, those ideas could help you.
  • 软件架构到底在解决什么问题?—— 跨团队沟通的问题
    • 在正常情况下,每个团队拥有开发和维护其特性所需的一切,都应该有自己的能力来完成自己的特性,并最大限度地减少团队要求其他部门获得许可和/或帮助。
    • 当引入 library 或 framework 时的好处是只需要少数人讨论,而不用涉及超过 100 人的决策和他们的各种需求。这样一场大讨论不仅会耗费时间和精力,而且会迫使我们采用最不起眼的方法来选择 library,而不是选择专门针对每个 team 的问题领域的方案。

所谓架构,其实是解决人的问题;所谓敏捷,其实是解决沟通的问题;

附:参考资料

本次技术雷达「微前端」主题的宣讲 Slides 可以在我的博客找到:「技术雷达」之 Micro Frontends:微前端 – 将微服务理念扩展到前端开发 – 吕立青的博客


更多精彩洞见,请关注微信公众号:思特沃克

Share

「微前端」- 将微服务理念扩展到前端开发(理论篇)

前言

在 ThoughtWorks 正式发布的最新一期技术雷达当中,「微前端(Micro Fontends)」已经进入到试验阶段,而试验环所列出的技术是我们认为值得去追求的。理解如何建立这种能力对你所在的组织十分重要,现在就可以尝试在一个低风险的项目上试点和实践这项技术,帮助你真正了解这门技术。

摘自最新一期技术雷达:

我们已经从引入微服务架构中获得了明显的好处,微服务架构可以让团队裁剪出独立部署的交付物以及可维护的服务。不幸的是,我们还看到许多团队在后端服务之上创建了前端单体——一个单一、庞大和杂乱无绪的浏览器应用。我们首选的(经过验证的)方法是将基于浏览器的代码拆分成微前端。在这种方法中,Web 应用程序被分解为多个特性,每个特性都由不同的前后端团队拥有。这确保每个特性都独立于其他特性开发,测试和部署。这样可以使用多种技术来重新组合特性——有时候是页面,有时候是组件——最终整合成一个内聚的用户体验。

文章大纲:

  • 微前端的缘由:单体应用与微服务架构
    • 微服务架构带来了哪些好处?
    • 那么前端的现状呢? —— 臃肿的前端
  • 微前端的定义 – 将微服务理念扩展到前端开发
    • 微前端的核心思想
    • 拆分微前端所带来的好处

微前端的缘由:单体应用与微服务架构

在传统的软件开发当中,大多数软件都是单体式应用架构。在瞬息万变的商业时代背景下,企业必须学会适应这个时代的不确定性。快速试验、快速失败、更快地推出新产品以及有效改进当前产品,从而为客户提供有意义的数字体验。

而单体应用这种软件架构对于企业来说有一个致命缺点——会致使企业对于市场的响应速度变慢。企业决策者在一年内需要做的决策数量非常有限,由于存在依赖关系,其响应周期往往会变得非常漫长。每当开发或升级产品,都需要在一系列体量庞大的相关服务中同时增加新功能,这就需要所有利益相关方共同努力,以同步方式进行变更。

微服务架构带来了哪些好处?

假设服务边界已经被正确地定义为可独立运行的业务领域,并确保在微服务设计中遵循诸多最佳实践。那么至少会在以下几个方面获得显而易见的好处:

  • 复杂性:服务可以更好地分离,每一个服务都足够小,能够完成完整的定义清晰的职责;
  • 扩展性:每一个服务可以独立横向扩展以满足业务伸缩性,并减少资源的不必要消耗;
  • 灵活性:每一个服务可以独立失败,允许每个团队自主选择最适合他们的技术和基础架构;
  • 敏捷性:每一个服务都可以独立开发,测试和部署,并允许团队独立扩展和维护各自的部署服务。

每个微服务是孤立、独立的「模块」,它们共同为更高的逻辑目的服务。微服务之间通过契约彼此沟通,每个服务都负责特定的功能。这使得每个服务都能够保持简单、简洁和可测试性。

在这一基础上微服务架构允许企业更自发地采取更深远的业务决策,因为每个微服务都是独立运作的,而且每一个管理团队可以很好地控制该服务的变更。

那么前端的现状呢? —— 臃肿的前端

(图片来自:http://t.cn/R8biudo

在前端,往往由一个前端团队创建并维护一个 Web 应用程序,使用 REST API 从后端服务获取数据。这样的做法能够提供优秀的用户体验,但会导致单页面应用(SPA)不能很好地扩展和部署。在一个大公司里,单前端团队可能成为一个发展瓶颈。随着时间的推移,由一个独立团队所开发的前端层往往会越来越难以维护。特别是一个特性丰富、功能强大的前端 Web 应用程序,却位于后端微服务架构之上时。随着业务的发展,前端会变得越来越臃肿,一个项目可能会有 90% 的前端代码,却只有非常薄的后端,这种情况在 Serverless 架构的背景下还会愈演愈烈。

微前端的定义 – 将微服务理念扩展到前端开发

微前端(Micro Frontends)这个术语其实就是微服务的衍生物。将微服务理念扩展到前端开发,同时构建多个完全自治、松耦合的 App 模块(服务),其中每个 App 模块只负责特定的 UI 元素和功能。

如果我们看到微服务提供给后端的好处,就可以更进一步将这些好处应用到前端。与此同时,在设计微服务的时候,就可以考虑不仅要完成后端逻辑,而且还要完成前端的视觉部分。而微前端与微服务的许多要求也是一致的:监控、日志、HealthCheck、Analytics 等等。

微前端的核心思想

  • Be Technology Agnostic:每个团队都应该能够选择并升级他们的技术栈,而不必与其他团队协调。自定义元素(后面会具体提到)是隐藏实现细节的好方法,同时为其他人提供公共接口。
  • Isolate Team Code:即使所有团队使用相同的框架,也不要共享运行时。构建独立的应用程序。不要依赖共享状态或全局变量。
  • Establish Team Prefixes:相互约定命名隔离。为 CSS、浏览器事件、Local Storage 和 Cookies 制定命名空间,以避免冲突,明确其所有权。
  • Favor Native Browser Features over Custom APIs:使用浏览器事件进行通信,而不是构建全局的 PubSub 系统。如果确实需要构建跨团队 API,请尽量保持简单。(与框架无关,可使用 CustomEvent)
  • Build a Resilient Site:即使 JavaScript 失败或尚未执行,Web 应用程序的功能仍应有效。可以使用通用渲染和渐进增强来提高用户的感知性能。

拆分微前端所带来的好处

拆分微前端能使各个前端团队按照自己的步调进行迭代,并随时准备就绪进入可发布状态,并隔离相互依赖所产生的风险,与此同时也更容易尝试新技术。

  • Web 应用程序被分解成独立的特征,并且每个特征都由不同的团队拥有,前端到后端。这确保了每个功能都是独立于其他功能开发、测试和部署的。
  • 将网站或 Web 应用程序视为由独立团队拥有的功能组合。每个团队都有一个独特的业务或关注点确定的任务。
  • 每一个团队是跨职能的,从数据库到用户界面端到端地开发其功能/特性。
  • 所有前端功能(身份验证,库存,购物车等)都是 Web 应用程序的一部分,并与后端(大部分时间通过 HTTP)进行通信,并将其分解为微服务。
  • 可以同时拥有后端、前端、数据访问层和数据库,即一个服务子域所需的所有内容。
  • 查找线上 bug、测试、框架迭代,甚至语言、代码隔离与责任和其他事情变得更容易处理。
  • 我们不得不付出的代价是部署,但是容器(Docker 和 Rocket)以及不可变服务器使得这种情况也得到了极大的改善。

续:微前端的实践方案

本文的下篇即技术雷达之「微前端」- 将微服务理念扩展到前端开发(实战篇)将逐一介绍微前端实战中超过 4 种的可选实践方案,并对多模块页面加载可能出现的问题与优化给出建议,最后对微前端的优缺点进行总结并提出了一些新的思考。


更多精彩洞见,请关注微信公众号:思特沃克

Share

Serverless实战:打造个人阅读追踪系统

阅读习惯和个人知识管理体系

进入互联网时代,知识的获取成本变得前所未有的低廉,但是无论再好的知识,若是没有对个人产生价值的话,那也只不过是一种信息噪音而已。我在《个人知识管理:知识的三种形态》这篇文章中使用“材料 -> 资料 -> 知识”这样的路径来诠释信息的流通,如何方便快捷并且有效地收集材料,再将其整理转化为有价值的个人知识体系结构,在这个信息极度碎片化的时代变得尤为重要。而在《去伪存真的知识管理之路》一文中也详细阐述了如何将网络上的碎片化文章纳入统一的稍后阅读体系,比如有时候在朋友圈看到一篇好文章,但暂时没时间直接看,或是这篇文章值得再读一遍,细读一遍,那么我就会将其存入稍后阅读工具即Instapaper当中,诸如此类的还有Pocket收趣等等。

稍后阅读中永远读不完的痛点:缺乏追踪

随着时间的推移,Instapaper里面的文章将会变得越来越多,就像我们在代码中所注释的TODO:可能就变成了Never Do,“稍后读”也是一样地被广为诟病:Read it Later=Read Never。其实我发现文章堆积的一个永恒痛点就是没有有效的方式追踪自己的阅读需求与能力,其核心原因在于阅读的速度赶不上添加的速度。从而没办法可视化的评估阅读进度、合理安排阅读计划,也就没办法给予自己适当的奖励,长此以往必然将失去阅读的动力。

在之前的一篇文章——《基于GitHub的敏捷学习方法之道与术》,其中提到使用GitHub Issue来管理自己的学习计划,于是就产生了这么一个想法——将我的稍后阅读列表跟GitHub结合起来,使用ZenHub丰富的图表功能将阅读体系进行追踪与可视化。

可视化Cumulative Flow Diagram

首先让我们直接来看一下最终的具体效果图,在这里简单介绍一下CFD(Cumulative Flow Diagram)即累积流图,这是一种能让你快速了解项目或产品工作概况的图表,关注的是价值的流动效率,价值的流动最直接的体现就是需求卡片在各个队列中的数量。

里特定律(Little’s law)告诉我们,交付时间(Delivery time)依赖于在制品数量(Work In Progress, WIP)。WIP是指所有已经初始但还未完成的工作,例如:所有在分析(Analysis)与完成(Done)之间的工作。首先需要留意的就是WIP,如果WIP增加了,交付日期就会有风险。ZenHub所提供的Release Report中最有效果的就是预测完成日期,总之就是跟敏捷方法结合起来,使用项目管理的方式来管理自己的阅读列表,虽然我还处在进一步的探索之中,但是每次看到这个走势图就能对自己的阅读列表有更多的掌控和理解,至少减少了因文章堆积而产生的焦虑感。

IFTTT与Serverless架构

那么这是怎么通过APIs来实现的呢?在真正进入正题之前我们先来简单介绍一下Serverless架构。Serverless指的是在构建Web应用程序的时候,不用担心如何配置服务器,但是这并不意味着应用程序不会在服务器上运行,而是说服务器的管理都可以尽可能地交给相应的云平台,从而最大程度地减轻开发人员的部署与配置工作。与之对应的一个名词可能就是Function As a Service(FAAS),由AWS Lambda这个命名就能想到,当我们在构建Serverless架构时,实际上我们是在写一个个的Function,即函数而已。

流程化:APIs即服务

首先让我们来介绍一下IFTTT即if this then that。通俗的来讲,IFTTT的作用就是当一件事情被触发时,能够执行设定好的另一件事。所谓的「事」,指的是各种应用、服务之间可以进行有趣的连锁反应。IFTTT的宗旨是Put the internet to work for you(让互联网为你服务)。用户可以在IFTTT里设定任何一个你需要的条件,当达成条件时,便会触发下一个指定好的动作。它就像是一座神奇的桥梁,能连接我们日常所用的各种网络服务。

而我们现在遇到的这个串联式的场景是特别合适Serverless架构的,使用IFTTT并且将它跟Instapaper账号绑定,设置文章添加、高亮、归档等行为作为trigger条件,然后将相关信息发到某一个指定API endpoint。先把操作GitHub Issue和ZenHub的各种APIs准备好,结合IFTTT的触发器与Marker工具能够非常方便地与之相集成,最后我们可以产出这样一个APIs交互流程图:

初始化Webtask项目

虽然AWS Lambda是Serverless架构的典范,但它也有一些槽点,而且我觉得已经被人说得足够多了,所以我们今天就来尝尝鲜,着重介绍和使用一下Webtask。你可能没有听说过推出该服务的这家公司——Auth0,但你一定知道大名鼎鼎的JWT即JSON Web Token,这是一种开放标准(RFC 7519),通常被运用在身份验证(Authentication)和信息交换等需要安全传输信息的场景下。

首先让我们来安装工具初始化项目以及注册账号,然后使用电子邮件进行登录:

npm install -g wt-cli
wt init <YOUR-EMAIL>

创建项目目录,添加index.js文件并添加以下内容:

module.exports = function (cb) {
  cb(null, 'Hello World');
}

然后在该目录中运行以下命令,进行应用程序部署之后,点击控制台中输出的URL就能看到编程史上最有名气、没有之一的HelloWorld!:

wt create index

Webtask的上下文绑定

Webtask有一个实用工具webtask-tools,可以将应用程序绑定到Webtask上下文,让我们将之前所export的简单函数修改为绑定到Webtask的Express app,然后就可以愉快地使用Express进行开发,一切就又回到了熟悉的轨道:

app.use(bodyParser.urlencoded({ extended: false }))
app.use(bodyParser.json())

require('./routes/reading')(app)

module.exports = Webtask.fromExpress(app)

Webtask context还有一个非常重要的用途,就是在部署时传输一些敏感信息,比如安全Token,从而在应用程序当中随时使用它们。下面的部署命令中–secret后面所传入的ACCESS_TOKEN都会在后续与GitHub和ZenHub APIs交互时被用到。

wt create index --bundle --secret GITHUB_ACCESS_TOKEN=$GITHUB_ACCESS_TOKEN 
--secretZENHUB_ACCESS_TOKEN=$ZENHUB_ACCESS_TOKEN --secret
ZENHUB_ACCESS_TOKEN_V4=$ZENHUB_ACCESS_TOKEN_V4

# ./routes/reading.js
module.exports = (app) => {
  app.post('/reading', (req, res) => {
    const { GITHUB_ACCESS_TOKEN, ZENHUB_ACCESS_TOKEN, ZENHUB_ACCESS_TOKEN_V4 } = req.webtaskContext.secrets
    }
}

使用GitHub Issue追踪阅读列表

IFTTT:添加Instapaper文章后自动创建GitHub Issue

得益于IFTTT非常丰富的第三方服务,IFTTT可以直接创建Instapaper与GitHub Issue相集成的Applet:If new item saved, then create a new issue – IFTTT,就可以在当Instapaper新增文章的时候,自动在GitHub所指定的仓库Issues · JimmyLv/reading 中创建一个新的Issue并添加相应的标题、链接以及描述等相关信息。

但仅仅只是添加一个Issue还不够,这时候还需要将这个Issue加入到指定的Milestone以便利用ZenHub的图表功能,使用GitHub的Webhooks功能就可以轻松帮我们把Issue更新的状态转发到我们所指定的Webtask地址:

使用GitHub Webhook 更新Issue的Milestone

所以我们的Webtask就需要处理GitHub Webhook所转发的POST请求,其中包括了Issue的类型和内容,在拿到’opened’即新建Issue类型的action之后我们可以对其进行相应的处理,即添加到Milestone当中:

if (action === 'opened') {
  fetch(`${url}?access_token=${GITHUB_ACCESS_TOKEN}`, {
    method: 'PATCH',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      milestone: 1
    })
  })

}

结合ZenHub的Milestone燃尽图我们可以清晰地看到剩余阅读量,并且能够跟理想中的阅读速度进行对比,从而判断自己什么时候能够全部读完所有的文章。可能有些小伙伴看到这里会有所疑问,这些所谓的Story Point是从哪儿来的呢?接下来就要提到我们将要集成的ZenHub API了。

集成ZenHub API:阅读可视化

更新Issue的估点和Release

GitHub Issue的任何变动都会触发Webhook,因此我们可以在Issue被加入Milestone之后再处理下一个’milestoned’ action,即:

if (action === 'milestoned') {
fetch(`https://api.zenhub.io/p1/repositories/${REPO_ID}/issues/${number}/estimate?access_token=${ZENHUB_ACCESS_TOKEN}`, {
    method: 'PUT',
    body: JSON.stringify({ estimate: 1 })
  })
    .then(() => {
      return 
fetch(`https://api.zenhub.io/v4/reports/release/591dc19e81a6781f839705b9/items/issues?access_token=${ZENHUB_ACCESS_TOKEN_V4}`,
        {
          method: 'POST',

        })
    })
}

这样我们就完成了对每个GitHub Issue的估点,以及设置了对应的Release,接下来所有的变动都将体现在ZenHub的图表当中。

归档Instapaper文章后关闭GitHub Issue

说了这么多,不要忘了整个阅读系统最最核心的部分依然还是「阅读」啊!在众多的稍后阅读工具中我无比喜爱Instapaper并迟迟没有转到Diigo的原因就在于它优秀、简洁、纯粹的阅读体验,让人可以专注在阅读本身这件事情上,在被Pinterest收购之后更是将所有的诸如全文搜索、无限高亮/笔记、速读等Premium功能都变成了免费,岂不美哉?

那么在完成阅读归档之后,最后一步就是在GitHub当中将Issue关闭掉,但是IFTTT的GitHub服务并没有提供close Issue的接口,于是乎我们就只有利用IFTTT新推出的Maker自己创建一个,即将Instapaper规划作为一个IF trigger,然后用Maker发出一个Web请求,可以是GET、PUT、POST、HEAD、DELETE、PATCH或者OPTIONS之中的任何一种,你甚至还可以制定Content Type和Body。

app.get('/reading', (req, res) => {
    const { GITHUB_ACCESS_TOKEN } = req.webtaskContext.secrets
    const title = req.query.title
    let keyword = encodeURIComponent(title.replace(/\s/g, '+'))

fetch(`https://api.github.com/search/issues?q=${keyword}%20repo:jimmylv/reading`)
    .then(data => {
          if (data.total_count > 0) {
        data.items.forEach(({ url, html_url }) =>
          fetch(`${url}?access_token=${GITHUB_ACCESS_TOKEN}`, {
              method: 'PATCH',
              headers: { 'Content-Type': 'application/json' },
              body: JSON.stringify({ state: 'closed' }),
            })
                   }
    })
}

上述代码就可以用于处理IFTTT Marker所发送的GET请求,我们从query参数中取到文章标题之后再去搜索相对应的Issues,再通过GitHub API将其关闭。

而与此同时,我们在文章的阅读过程中,有时候也会想要对文章中的亮点部分进行高亮,甚至添加自己的一些想法和总结,那我们也可以用IFTTT Marker和Webtask的套路添加至GitHub Issues的comments当中。具体的详细代码就不贴了,更多内容都已经放在我的GitHub上:JimmyLv/demo.serverless-mern,与此同时我的阅读列表也公开在GitHub上:Issues · JimmyLv/reading,欢迎围观。

总结与后续计划

随着时间的推移,日常你只需要在Instapaper添加并阅读文章即可,而背后利用Serverless所搭建的整套阅读追踪系统将会任劳任怨的帮你记录下所有的踪迹和笔记,你只需要在特定的时候定期review、分析阅读的效果与预测效果,与此同时结合自己的时间统计系统,持续不断地改进自己的阅读目标与阅读计划。

最后再来考虑一下后续计划,比如说我现在只是简单把Instapaper中高亮部分和阅读笔记作为评论放到GitHub的comments里面,但是最终我需要把它收藏到自己的个人知识库即Diigo,这也是可以通过API自动实现的,以及最终需要被刻意记忆的部分还需要与Tinycards或者QuizletAPI相集成,对抗艾宾浩斯遗忘曲线。

与此同时,还需要根据文章类型和难易程度具体划分一下估点,而不是现在简简单单的1点,比如说Instapaper也有根据字数来预测的阅读分钟数,以及根据中文或英文、技术或鸡汤等不同种类文章阅读难度进行区分,从而使整套追踪系统更具有效性与参考性。


更多精彩洞见,请关注微信公众号:思特沃克

Share

基于GitHub的敏捷学习方法之道与术

持续行动,持续反思,持续进步。—— via. 敏捷学习宣言

前言

对时间的敬畏

需要好多年才能懂得,最好不是去震惊世界,而是要像易卜生所说的,生活在世界上。

我们都一样,渴望着建树功勋、改变世界。可是伴随着年岁的增长,却发现梦想仍旧遥远,而时间却依然残酷的流逝着,不会仅仅因为「你」而发生丝毫的改变。如《奇特的一生》当中所言,我对时间始终充满着敬畏之心,最好的方式也不过是奢求时间能够跟自己做朋友,伴随着我这也许注定朴实无华的一生,共同成长。

在我们一生所能做的事情里,睡眠占去 1/3,此生只剩 2/3,除去非做不可的基本生活维护成本之外,剩下的时间要么选择浪费而荒度此生,要么瞄准目标而奋力向前,让这一生不留遗憾。Follow your heart,你需要找到一些愿意为其付诸终身的「目标」,以这样的姿态「生活在这世界上」。

敏捷与个人成长

就像软件开发一样,一个人的成长也应该有自己的方法论。人的一生若是顺风顺水、一成不变,那未免太无趣了,正是由于世界的未知在等着我们去探索,不一样的经历才会让人感到惊喜和有趣。想做的事情永远都不会嫌多,就像柳比歇夫最开始是研究生物学的,却在科学的道路上越走越远,进而研究起了数学、物理、哲学,甚至于美学,而更关键的是,他在每一方面都做出了很大贡献并且留下了诸多著作。

时间充当着 Product Owner 的角色在不断向你提出各种各样的需求,敏捷当中最重要的一大前提就是「拥抱变化」,而在「记录时间这件小事儿」里面我提到的GTD流程便可以用于处理这源源不断的需求,即收集、整理、执行、回顾,对应到敏捷当中的几大会议,显然也可以由个人完成,自己就是自己的 IM & PM,当然也是 BA & Dev & QA(当然不用担心人格分裂)。

实践之术

我都没想到怎么写着写着就把开头写成了鸡汤文。但是咧,如果前面讲的是「道」,那么接下来就会具体到基于 GitHub 的「术」,即各种实践。

首先,让我们从需求出发,从市面上来寻找一款符合敏捷的学习软件,别想了,当然是没有的。对于一名程序猿来说,最理想的答案其实就是 GitHub,作为全球最大的程序猿(交友)网站,GitHub 本身以及围绕 GitHub 的各种插件使得其项目管理能力远比你所能想象的厉害得多。

  • 收集:需求无时无刻,无处不在,anywhere anytime
  • 整理:as BA,即分析,Elaboration & Estimation & IPM => 确定 MVP & Efforts
  • 执行:as Dev & QA,Developing & Testing & Review/Sign-Off
  • 回顾:Retrospection,Introspection,持续反思,持续进步…

通过 GitHub Issues 收集需求

首先你可以给自己建一个 GitHub 仓库作为主页,比如我的 JimmyLv/jimmylv.github.io: Agile Learning based on GitHub issues ,最开始就是从个人博客的主仓库发展而来。那么,如何快速收纳自己的想法呢?以解决问题为导向,就是有什么需求就直接给自己的 repo 建一个 issue 作为 Story Card,了却这个需求的最终形态就是 close 掉这个 Issue,比如我要写这篇文章就始于这个 issue:基于 GitHub 的敏捷学习方法总结 · Issue #36

GitHub issues 的进阶用法

与此同时,新建 issue 还有更高级的用法,也就是通过 ISSUE_TEMPLATE 这样一个模板来新建某个 issue,从而更快地定位问题所在和解析自己的想法,最主要的是能够输出更具体的 TODOs,即下一步行动的具体内容,这个还会在后面详细解释。

  • issue 和 issue 之间是可以通过 # 相互连接,甚至可以跨仓库,被 reference 的 issue 也会出现在另外一边的 issue 里面;
  • 而通过 #! 符号是可以在 comments 里面直接新建一个 issue ,这在思维爆炸的时候来得特别爽快;
  • 你还可以随意艾特你的小伙伴们,互相监督、互相学习或者给出 Constructive Feedback 之类的,😂;
  • 更甚至于,若是在 Intellij 里面关联了 GitHub,就可以在 git commit 信息里面直接看到你所要关联的 issues 列表了。

这种方式仿佛学习中的大脑,神经网络被连通了的感觉。

移动端的解决方案

而在移动端则可以通过 GitDo 这个 App 来轻松新建和管理自己的 Issues,没错,就是有人把 GitHub issues 做成了一个 Todos 类 App,还做得很漂亮功能很完善。只是不知为何这软件最近被下架了,伤感,我就又重新把滴答清单(TickTick)作为自己的万能收集箱了,之后再把比较重要的、需要进一步追踪的事项添加到 GitHub issues 里面来。

整理你的 GitHub Issues

大胆地把 issues 作为你的个人需求列表吧,需要解决的问题可以大到做一个开源项目,或者小到读一本书、写一篇文章。对于比较大的需求,你还可以将其转化为 Epic 然后把拆分过后的小 issues 们加入到这个列表里面来。

而 GitHub (with ZenHub) 强大的 issues 管理能力绝对会让你的迭代工作变得井井有条,使用 GitHub 新出的 Projects 特性或者使用 ZenHub 的 Boards 就可以让你瞬间拥有日常敏捷工作的感觉了吧!

计划与执行具体任务

制定迭代计划

首先,让我们新建一个 Milestone 来制定计划,也就是决定在一个 Iteration 里面你需要完成哪些 issues。在这里我所制定的阶段性计划周期为一个月,当然你也可以勤快一点,以2周作为一个 Iteration,享受一下自己的计划要完成不了、这个 Milestone 就要废了,没法向「时间」这个一生的朋友交付所有需求的快感吧 :)

当然咯,一般我会在月初做计划的时候给自己准备专门的时间来做 Elaboration,把 Backlog 里面的卡拖到 Rethink/Plan 这一列,经过分析和详细输出 TODOs 以及所对应的估点 points 之后便可以将其拖到 Ready For Todo 了,一般我给自己估的点数就是完成这件事情所需要的时间,一小时即对应一个 point。

这样你就可以愉快的选择 Filter Issues by Milestone 专注于当前 Iteration,专注于 In Progress 这一列所要做的事情,并且垂涎于 Ready For Todo 里面将要做的事情,每次做完还可以放到 Review/SignOff,在里面写写对这件事情的总结和感想什么的,每次挪卡都充满了敏捷的仪式感(认真脸)。

进度的把控

GitHub 在 issues 里面直接集成了 Markdown 的 TODO 语法,甚至于可以在渲染过后直接拖动某个 item 进行排序,而且可以在前面的勾选项中直接打勾 ☑️ 标记为完成。不仅如此,完成之后这个 issue 还能直接显示完成进度;前面所提到的 Epic 也能直接显示子 issues 的完成情况即 closed 比例,两者结合起来简直不能再美好。

比如说拿来作为读书列表的记录就很不错,每本书作为一个 issue,还可以把章节划分为具体的 TODOs,结合估点追踪自己看书的进度和速度,顺便在 comments 底下做个笔记也不错啊!

专注当下

ZenHub 还提供了一个基于 GitHub Issues 的 To do List,你可以只关注 Today 这一个列表,专心于当前要完成的任务。而且更有趣的是这个 list 可以加入 GitHub 的任何 issues,也就是说它是全局的,所以你可以加入很多在 GitHub 上通过 issues 写的 blog,比如徐飞的这篇文章流动的数据——使用 RxJS 构造复杂单页应用的数据逻辑 · Issue #38 · xufei/blog,被我加入到了 Reading列表当中。

与此同时我还会使用 Toggl 来记录每个 issue 具体实施的时间,以便于在时间花费上能够获得及时的反馈。这样做会让你真切地感受到时间的流逝,而在回顾记录的时候也能够进行总结分析,从而在下一次的计划当中更精确地预估时间(点数)。比方说这篇文章我估了 5 个点现在已经写了 4.5 hours 了,不过这是另外一个大话题,可以参考 记录时间这件小事儿 这个 issue。

迭代回顾与总结分析

ZenHub 也提供了 Burndown 和 Velocity tracking 图,可以得出这个迭代总体的完成情况,看看跟预期有何不同;也可以跟其他迭代进行对比,看看有何不同的地方,然后进行下一步的具体分析。

还可以根据 GitHub 和 Toggl 里面的数据进行汇总和分析,下面这个表格就是我在 11 月这个迭代完成后一部分 issues 的具体 Estimation Points 和 Time Efforts,再结合 issues 里面所记录下的各种笔记和 references,来得到一个比较直观的总结和复盘。

Number & Description Estimation Points Time Efforts
#85 记录时间这件小事儿 3 04:26:18
#96 如何对时间进行分类? 8 03:00:09
#102 建立个人 Wiki 系统 2 02:53:56
#101 技术雷达宣讲:enzyme 测试框架 5 06:11:19
#90 Working time improvement 1 33:27 min
#97 如何使用 XX 的标签系统? 1 25:21 min
其他辅助工具
  • 看板:as Jira/Trello,可视化当前进度 => GitHub Issues group by @Projects / 日历 in @滴答清单;如果你不想用 ZenHub ,可以试试 Gitlo ,可以在 GitHub issues 和 Trello 之间进行双向同步。
  • 晨间日记/每日回顾:as Stand-Up,只用关注 Timeline/Done/Todo/Blocker 以及当天的心情/天气等等,使用 @格志日记的一个特点就是可以通过问答的方式对一天进行回顾。
  • 时间记录:@时间块的优点在于记录起来非常简单、快捷,是用户评论中最省时间的时间记录工具,没有之一,推荐新手试试。但由于个人需要更加详细的记录细节和报告分析,以及多平台(包括 Chrome Extension)的支持,从而选择了 @Toggl
  • 白噪声:作为一款时间记录工具,@Toggl 本身就支持 Pomodoro 的 25 分钟提示。而作为专注力辅助的白噪声软件我在手机上用的 @潮汐,电脑上则选择了 @Noizio

后话

也许你很喜欢这个解决方案但又不太想公开自己的 issues 列表,那可以试试 GitHub 的 private repo(需要付费),免费的可以试试 GitLab,支持从 GitHub 一键导入,并且已经原生支持了 pipeline 和看板功能。当然,不限于工具或软件,这一套方法论其实是可以运用在任何地方的,甚至于我们可以来做一个结合敏捷方法论的个人学习管理软件也不错。

但是于我而言,选择在 GitHub 这样一个公开环境下记录学习的最大一个动机就在于「开源」,很喜欢一句话,大意是「在这个互联网时代,能限制住学习的只有你的求知欲」。

当你从互联网这个广阔的知识海洋当中汲取知识时,也应当有所输出,即反哺到整个互联网当中去。我会经常写博客/笔记来总结、分享自己的所学,但是一篇文章诞生的背后往往还有很多其他知识和经验的相互交融与沉淀。Issues · JimmyLv/jimmylv.github.io 这个列表里面的某个 issues 最终能否演变成一篇文章我不知道,但是基于 GitHub 开放式的学习历程都会被这些 issues 如实地记录着,任何一个想法都能追本溯源被找出最开始的缘由。

相比于软件开发这件小事儿,健康快乐地成长显然要重要得多。—— 立青


更多精彩洞见,请关注微信公众号思特沃克

Share

使用Enzyme测试React(Native)组件

组件化与UI测试

在组件化出现之前,我们不谈UI的单元测试,哪怕是对于UI页面进行测试都是一件非常困难的事情。其实组件化并不完全是为了复用,很多情况下也恰恰是为了分治,使得我们可以分组件对UI页面进行开发,然后分别对其进行单元测试。

特别是当浏览器中的Web应用越来越庞大的时候,与在后端将大型单体应用拆分成微服务架构的最佳实践一样,前端应用也可以被拆分成不同的页面和特性。

(图片来自:http://t.cn/R6UgwrH)

每个特性由一个单独的团队从端到端对其负责,它允许团队规模化地交付那些能够独立部署和维护的服务,在2016年11月期的技术雷达当中这种方式被称之为微前端,微前端的目标就是允许Web应用的特性彼此独立,每个特性可以独立地开发、测试和部署。

React.js作为前端框架的后起之秀,却在2015年携着虚拟DOM、组件化、单向数据流等利器,给前端UI构建掀起了一波声势浩大的函数式新潮流。虽说组件化不是React最先提出来的,但却是被React在前端世界里发扬光大的,而现在几乎所有的所谓现代化UI框架比如Angular或者Vue都已经将组件化作为框架的立足之本。

React已经让UI测试变得容易很多,React组件都可以被简化为这样一个表达式,即UI=f(data),这个纯函数返回的只是一个描述UI组件应该是什么样子的虚拟DOM,本质上就是一个树形的数据结构。给这个纯函数输入一些应用程序的状态,就会得到相应的UI描述的输出,这个过程不会去直接操作实际的UI元素,也不会产生所谓的副作用。

React组件树的测试

按理来说按照纯函数这样的思路,React组件的测试应该很简单。但与此同时,对于(渲染出UI的)组件树进行测试依然存在一个问题,从下图中可以看出,越处于上层的组件,其复杂度越高。对于最底层的子组件来说,我们可以很容易的将其进行渲染并测试其逻辑正确与否,但对于较上层的父组件来说,就需要对其所包含的所有子组件都进行预先渲染,甚至于最上面的组件需要渲染出整个 UI 页面的真实DOM节点才能对其进行测试,这显然是不可取的。

Shallow rendering lets you render a component “one level deep” and assert facts about what its render method returns, without worrying about the behavior of child components, which are not instantiated or rendered. This does not require a DOM.

浅渲染(Shallow Rendering)解决了这个问题,也就是说在我们针对某个上层组件进行测试时,可以不用渲染它的子组件,所以就不用再担心子组件的表现和行为,这样就可以只对特定组件的逻辑及其渲染输出进行测试了。Facebook官方提供了react-addons-test-utils可以让我们使用浅渲染这个特性,用于测试虚拟DOM对象,即React.Component的实例。

使用Enzyme简化测试代码

我们常常会提到,测试代码对于复杂代码库的可维护性至关重要,但是测试代码本身的易于理解和编写,以及可读性和可维护性也同等重要

Enzyme is a JavaScript Testing utility for React that makes it easier to assert, manipulate, and traverse your React Components’ output.

而Enzyme则来自于活跃在JavaScript开源社区的Airbnb公司,是对官方测试工具库(react-addons-test-utils)的封装,它模拟了jQuery的API,非常直观并且易于使用和学习,提供了一些与众不同的接口和方法来减少测试的样板代码,方便你判断、操纵和遍历React Components的输出,并且减少了测试代码和实现代码之间的耦合。Enzyme理论上应该与所有TestRunner和断言库相兼容,已经集成了多种测试类库,比如Jest、Mocha&Chai、Jasmine,不过这些不是我们今天的重点。

对比一下两者facebook/react-addons-test-utils vs airbnb/enzyme的API就一目了然,立见分明:

Enzyme的三种渲染方法

shallow(node[, options]) => ShallowWrapper

shallow方法就是对官方的Shallow Rendering的封装,浅渲染在将一个组件作为一个单元进行测试的时候非常有用,可以确保你的测试不会去间接断言子组件的行为。shallow方法只会渲染出组件的第一层DOM结构,其嵌套的子组件不会被渲染出来,从而使得渲染的效率更高,单元测试的速度也会更快。

import { shallow } from 'enzyme'
describe('Enzyme Shallow', () => {
  it('App should have three <Todo /> components', () => {
   const app = shallow(<App />)
   expect(app.find('Todo')).to.have.length(3)
  })
}

mount(node[, options]) => ReactWrapper

mount方法则会将React组件渲染为真实的DOM节点,特别是在你依赖真实的DOM结构必须存在的情况下,比如说按钮的点击事件。完全的DOM渲染需要在全局范围内提供完整的DOM API, 这也就意味着它必须在至少“看起来像”浏览器环境的环境中运行,如果不想在浏览器中运行测试,推荐使用mount的方法是依赖于一个名为jsdom的库,它本质上是一个完全在JavaScript中实现的headless浏览器。

import { mount } from 'enzyme'
describe('Enzyme Mount', () => {
  it('should delete Todo when click button', () => {
   const app = mount(<App />)
   const todoLength = app.find('li').length
   app.find('button.delete').at(0).simulate('click')
   expect(app.find('li').length).to.equal(todoLength - 1)
  })
})

render(node[, options]) => CheerioWrapper

render方法则会将React组件渲染成静态的HTML字符串,返回的是一个Cheerio实例对象,采用的是一个第三方的HTML解析库Cheerio,官方的解释是「我们相信Cheerio可以非常好地处理HTML的解析和遍历,再重复造轮子只能算是一种损失」。这个CheerioWrapper可以用于分析最终结果的HTML代码结构,它的API跟shallow和mount方法的API都保持基本一致。

import { render } from 'enzyme'
describe('Enzyme Render', () => {
  it('Todo item should not have todo-done class', () => {
   const app = render(<App />)
   expect(app.find('.todo-done').length).to.equal(0)
   expect(app.contains(<div className="todo" />)).to.equal(true)
  })
})

Enzyme 的 API 方法

find() 方法与选择器

从前面的示例代码中可以看到,无论哪种渲染方式所返回的wrapper都有一个.find()方法,它接受一个selector参数,然后返回一个类型相同的wrapper对象,里面包含了所有符合条件的子组件。在这个对象的基础上,at方法则可以返回指定位置的子组件,simulate方法可以在这个组件上模拟触发某种行为。

Enzyme中的Selectors即选择器类似于CSS选择器,但是只支持非常简单的CSS选择器,如果需要支持复杂的CSS选择器,就需要引入react-dom模块的findDOMNode方法,而这是官方的TestUtils都无法提供的方式。

/* CSS Selector */
wrapper.find('.foo') //class syntax
wrapper.find('input') //tag syntax
wrapper.find('#foo') //id syntax
wrapper.find('[htmlFor="foo"]') //prop syntax

Selectors也可以是许多其他的东西,以便于在Enzyme的wrapper中轻松地指定想要查找的节点,在下面的示例中,我们可以通过React组件构造函数的引用找到该组件,也可以基于React的displayName来查找组件,如果一个组件存在于渲染树中,其中设置了displayName并且它的第一个字符为大写字母,就能通过字符串找到它,与此同时也可以基于React组件属性的子集来查找组件和节点。

/* Component Constructor */
wrapper.find(ChildrenComponent)
myComponent.displayName = 'ChildrenComponent'
wrapper.find('ChildrenComponent')
/* Object Property Selector */
const wrapper = mount(
  <div>
   <span foo={3} bar={false} title="baz" />
  </div>
)
wrapper.find({ foo: 3 })
wrapper.find({ bar: false })
wrapper.find({ title: 'baz'})

测试组件的交互行为

我们不但可以通过find方法查找DOM元素,还可以通过simulate方法在组件上模拟触发某个DOM事件,比如Click,Change等等。对于浅渲染来说,事件模拟并不会像真实环境中所预期的那样进行传播,因此我们必须在一个已经设置好了事件处理方法的实际节点上调用,实际上.simulate()方法将会根据模拟的事件触发这个组件的prop。例如,.simulate(‘click’) 实际上会获取onClick prop并调用它。

Sinon则是一个可以用来Mock和Stub数据代码的第三方测试工具库,当我们需要检查一个组件当中某个特定的函数是否被调用时,我们可以使用sinon.spy()方法监视所传入该组件作为prop的onButtonClick方法,然后再通过wrapper的simulate方法模拟一个Click事件,最终验证这个被spy的onButtonClick函数是否被调用。

it('simulates click events', () => { 
  const onButtonClick = sinon.spy()
  const wrapper = shallow(
   <Foo onButtonClick={onButtonClick} />
  )
  wrapper.find('button').simulate('click')
  expect(onButtonClick.calledOnce).to.be.true
})

如何测试 React Native?

前面我们所谈论的都是如何测试使用react-dom所构建的React组件,即最终渲染的结果是浏览器当中的DOM结构,但对于React Native来说,JavaScript代码最终会被编译并用于调用iOS或Android上的Native代码,因此无法再使用基于DOM的测试工具了。

(图片来自:http://t.cn/R6UrTrG)

与此同时,React Native还有特别多的Mobile环境依赖,所以在没有真实设备的情况下很难对其运行环境进行模拟,特别是当你希望在持续集成服务器(如Jenkins、Travis CI)运行单元测试的时候。

事实上,我们可以通过欺骗React Native让它返回常规的React组件而不是Native组件,然后就又能愉快地使用传统的JavaScript测试库来单独测试React Native组件逻辑。最基本的mock示例代码如下:

const mockComponent = (type) => {
  return React.createClass({
   displayName: type,
   propTypes: {
     children: React.PropTypes.node
   },
   render() {
     return <div {...this.props}>{this.props.children}</div>
   }
  })
}
RN.View = mockComponent("View")
RN.Text = mockComponent("Text")
RN.Image = mockComponent("Image")

Enzyme推荐在测试环境中使用react-native-mock这个辅助库,这是一个使用纯JavaScript将全部的React Native组件进行mock的第三方库,只需要导入这个库就可以对React Native组件进行渲染和测试。

总结

上一期技术雷达中指出:我们非常享受Enzyme为React.js应用提供的快速组件级UI测试功能。与许多其他基于快照的测试框架不同,Enzyme允许开发者在不进行设备渲染的情况下做测试,从而实现速度更快、粒度更小的测试。在开发React应用时,我们经常需要做大量的功能测试,而Enzyme可以在大规模地减少功能测试数量上做出贡献。

(图片来自2016年11月期技术雷达)

最新一卷技术雷达将于3月28日全球发布,现在就去订阅,获悉一手技术雷达发布消息。


更多精彩洞见,请关注微信公众号:思特沃克

Share