我们知道页面是 web 设计中单次呈现给用户的一个功能整体，但功能的粒度随着 AJAX 的出现不仅仅限于表单即 form 与服务器的单次交互，变成了 XMLHTTPRequest 或 fetch 甚至 WebSocket 的多次往返，这样而言单一页面也可以承载更多的用户交互行为。与之同时带来的问题是如何有效划分功能区域以便实现最大程度的组件化，增强复用性和可维护性？

签约与填写身份信息分离

以某次产品设计为例，产品需要将 签署合同 和 填写身份信息 作为一个步骤页面放到拉力赛作品的创建流程里，原先的页面长成下图这样。

产品的想法是直接复用这个页面，作为前端当即表达了反对：这个页面包含了签协议和填信息两种操作，但却共用一个接口，不利于今后业务逻辑更为复杂时拆分（当下就已经属于过度耦合了），建议将 填写身份信息 放到单独的页面去。但产品随即表达了反对，认为用户的操作流程不应该多一个页面跳转。这怎么办呢？

用弹窗啊！

弹窗作为一种全局模态框可以在不修改整体页面流式布局的基础上让用户看到额外信息，甚至进行交互操作。弹窗内的组件可以被复用，因为是动态挂载到页面上的，一般对页面已有数据的依赖较小。

在实际代码构建时为了便于使用，将整个弹窗加上作者身份数据的获取、存储与更新逻辑整体封装到了一个 hook 中：

1

const { agentInfo, loaded, showAgentInfoFormDialog } = useAgentInfo(agentId)

这样将数据和方法返回给调用方，将代码的侵入性做到最低。如果以后有只需要身份信息而不需要修改弹窗的使用情形，也可以尽情复用。

更通用的标签筛选

一日接到了一个增加筛选器筛选条件的需求（筛选器是一个巨大的，有着上百个 CheckBox，相比各种电商筛选条件毫不逊色的怪物👹）。

作为一个凡是遇到需求不杠一杠就不开心的开发，我理直气壮地提出了自己的看法：这种一次性使用的需求，会在文件里留下谜一样的代码，而且根本不可能实现复用，如果要重构或者迁移都会是巨大的沉没成本。

随后根据下图的需求来源项

提取出了可以重复利用的「标签输入框」

有人会问，这样经常需要输入特定标签会不会不方便呢？早就想过啦，可以使用「加入书签」功能

会映射成形如 /admin/editorial_service?tags=亲密关系+轻装上场 的 url 存储在 localStorage 中，方便下次使用。大功告成！

总结

通用设计可以提供组件的复用能力，尽可能做到少暴露接口给外界，毕竟多一行代码就多一分风险和维护的成本，同时通用性足够好的情形下也能促进产品往更高效的方向发展，而不是拘泥于小而美的自我天地。

2020 年目前在做的最复杂的项目是将基于 Draft.js 深度定制开发的 web 编辑器适配到移动端，因为数据上牵涉到很多转换过程 native 端要从头开发的话成本过高，并且发现 web 并不能很正常地识别虚拟键盘弹出与否，于是将下图所示的工具栏通过 native 端单独进行开发与 web 集成，以获得更好的使用体验。

简单介绍下 web – native 通讯方式，ark_editor_native 是 native webview 注入到 window 对象上的一系列方法简称 AEN，ark_editor_web 则是 web 编辑器挂载成功后写入到 window 对象上供 native 调用的一系列方法简称 AEW，每次 editor 有任何更新，通过 AEN.syncState 传递给 native 一个 JSON 字符串，客户端需要自行反序列化成 JSON 对象，称为 syncState。

syncState

操作栏

优先级原则：

• 先判断是不是 disabled
• toggle > native 帮我 > 交给你了 web > insert/update/remove

上面就是编辑器跨端通讯的基本形式了，简单来说 web 端每次 React componentDidUpdate 会把状态同步给 native 端，保证工具栏的及时性。当用户点击工具栏中可用按钮时，首先判断是不是需要和 web 进行状态判断，毕竟前一步只是判断能不能触发，触发以后的行为需要结合更具体的数据状态。然后是如果发现需要更多用户输入（比如弹窗输入框或勾选项等等）就需要唤起 native 的方法（native 帮帮我），如果没有这一步就可能是 web 专享操作，无关更多状态，比如上传图片或者撤销重做等等，这种情况就全权交给 web 了。最后则是 native 端二次调用 web 的方法，通常是关掉弹窗以后传递数据去改变 web 的状态。

体会：

• 原本通过 React props 保证的数据实时性需要手动同步给 native 端
• native 和 web 互相暴露方法需要考虑实现的最小集
• 需要找到优雅的 debug 方式，出现过直接传 JS Object，native 端得到 undefined
• 异步操作可能需要加锁

当然现在开发还在对接联调期，包括保存等功能还没有加上，与从零开始的搭建也不可同日而语。编辑器和阅读器都是电子阅读产品的重头戏，之前则是看了这篇《Visual Studio Code有哪些工程方面的亮点》，对编辑器的开发充满了崇敬的心情。VS Code 也是我们现在开发的主力工具，包括其丰富的插件体系、LSP 和宛如神器的 Remote 模式，都使我惊叹于其良好的实现。不说了，去下单《设计模式》了。

在股市的朋友一般都知道「K 线图」这个东西，简单说来就是包含四个数据，即开盘价、最高价、最低价、收盘价，所有的 K 线都是围绕这四个数据展开，反映大势的状况和价格信息。我的姨夫号称一代股神，开一次张可以吃三年，特别崇拜这个图。我个人是有些不以为然的，因为 T + 1 制度的存在杜绝了超短线投机。任何时刻的交易都是基于前一时刻的交易，如果这种方式是靠谱的，那也只是扒下了边际效益的薄薄一层皮而已。如果要做超短线就是期货了，曾有个笑话说炒期货的要尿个尿都要把手上的先抛掉才敢去尿。这就是时滞效应。

当前华夏大地处在一片新型肺炎疫情的阴霾笼罩之下，时隔 1 – 14 天不等的发病周期，让防疫工作困难重重。一旦某个小区发现感染病例，整个小区都会被隔离。我们可以看下下面这张疫情趋势图，图中可见疑似病例一开始是低于确诊病例的，但年初二之后突然呈井喷般上升趋势，但幸好当下已经逐渐趋于平稳。

没有疑似病例意味着什么，意味着毫无病例筛查。疑似病例井喷说明什么，说明堆积了足够多的样本上报。量变引发质变，足够多的病例将导致疾病向着失控的方向蔓延，而这一切在确诊病例上是延时的，不确切的。所以需要更多的筛查渠道和病毒检测盒，而现在更可怕的是病毒会“伪装”自己，在感染的前 10 天并无法检查出阳性，这样就给医学意义上的密切接触者数量更提升了一个数量级。

而反观政府现在在做什么？隔离，对，隔离是必要的。区域自治，区域封锁，假期延长，将蔓延的机会降到最低。另外一点，隔离使得城市面临生活必需品保障短缺的问题，各级政府苦心经营的第三产业在疫情面前已经濒临瘫痪，第二产业随着机器人的大量应用其实已经实现了自治，但第一产业 —— 农业，依然是需要保障的重中之重，农产品需要从城市就近通过内部交通网络输送到各家各户，而这些都是都市人口已经很久很久没有考虑过的了。

所以说，这次疫情之类最应当做的两个工作是：

1. 深化医疗行业的规范改革，切实保障一线医务工作者的安全以及避免就诊患者交叉感染。
2. 大力发展现代农牧业，例如屋顶大棚果蔬养殖和人工智能养猪等等，保障危急时刻群众吃饭问题。

都市人已经习惯了吃饭了叫个外卖，生病了挂个号慢慢排队的日子，这次疫情让人体会到时间的宝贵，不珍惜时间就会浪费更多的时间（假期）来弥补时间的亏空。在商业软件开发中也是一样，不尊重用户的日常需求，用户切实反馈的问题得不到解决，用户的怨言就会堆积起来，最终导致用户流失。而对于自身而言，每天投资自己一点点，自己变好一点点，就是增强一点点今后的抗风险能力。