疫情期间每天都是自己做饭吃，隔两三天就要买一次菜，每次买菜光是拆包装盒就要耗费非常多的心力，更别提清洗食材和锅碗，切菜淘米调配料，蒸炒炖炸等工序了，难怪说疫情期间分手的情侣、离婚的夫妻比比皆是，敢情大家平时都是装作很会生活的样子，一旦没了外卖快递都退回到了饮毛汝血的状态。

正如做饭 1 小时，吃饭 10 分钟，洗碗半小时所说的那样，吃这样一个动作在当前都会有无穷的副作用，可以说现代都市生活真的是建立在非常完善的 O2O 服务行业之下的，要吃饭线上下个单线下送来，要保洁自如下个单线下保洁员上门，要 ml 都有 165/90 32C 的家政服务人员上门服务。人的生活变成了只需处理工作，其他时间都可以用钱买到，这样 WFH 所带来的工作时长延长对社畜的身心打击几乎到了极致。扯远了。

网上买菜或者超市买菜，相比于菜市场买菜最大的区别是包装。垃圾桶里丢掉的绝大部分是塑料包装而不是切掉的边角料菜或者剩饭剩菜。就像软件开发里，动辄几十上百层的封装之下，真正工作的是那么一两行代码。

1. public
2. js
3. submit
4. works
5. manage
6. components
7. header-actions
8. PriceActions
9. PriceActions.tsx -> StartPromotionButton.tsx -> StartPromotionForm.tsx

一个页面上小小的组件，被封装在 9 层目录之下，同目录平级之间还有嵌套关系。当然组件化分治思想也是 React 一直火到现在的根本原因，但有时也会想想这种扁平化的目录结构是否真的合适项目的发展，或者说在业务需求猛增前提下如何科学组织目录结构以便修改维护也是门学问了，当然最好的方式是：不组织。根据实际发展来让文件自行组织，见 destiny。

拉扯这么多包装的弊端，但包装实际上是一项很重要的工序，因为不包装带来的风险，往往是看不见的：
小吕去年写了个活动页的接口，因为是第一次办这种活动，小吕本着以产品需求为约束的理念写好了无届数限制的 API 接口，然后前端同学以此接口封装了一个组件给页面加了上去。转眼间一年过去了，活动办了第二届，产品要求有新功能，小吕又哼哧哼哧写了一个第二届活动的 API，但这时候出分歧了：前端觉得接口应该稳定，如果每做一届都要回溯一遍做过的接口映射，太累且容易出错；而后端觉得分离 API 有助于更清晰地业务逻辑。大家说的都没错，怎么办呢？包装一下接口吧！

可以看出是适当的包装有助于分清业务界限，明确各端职责是非常值得提倡的。

但为什么实践中经常分不清这些呢？因为 Python 本质是一个胶水语言，更多起黏合剂作用，而 JavaScript 更想火柴棍，可以飞速搭原型，但两者都不是拥有持续集成性和可维护性的代表。个人以为类型系统以及所有权（或者说内存锁）是一个合格的工业级语言必备的，一个保障 AOT 安全，一个保障 JIT 安全，任何业务逻辑都是对这两个基本原则的封装。

我们知道页面是 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 模式，都使我惊叹于其良好的实现。不说了，去下单《设计模式》了。