序言

本文就如何设计多端容器做出实现方案。本文指的多端并非是跨端，多端容器泛指容器提供统一能力，以供下游应用在多种环境下的容器加载并正常运行。各端容器提供的能力可能不同，下游也无需关心上层实现及依赖，只依赖于抽象接口，遵循依赖反转原则。

小伙伴应该接触过以下这种需求场景：应用既可以在web browser运行，也可以以Hybrid的方式内嵌 webview、三方应用(alipay,wx,微应用等)浏览器。可能有些同学会问：“同是 Browser Environment，提供的上下文能力不都一样吗”，但实际上，会有一些容器对加载内容的能力做一些限制和添加特色功能，端容器需要做的就是将它们对齐。当处于可以访问DOM的环境调用社区的动画库，处于原生应用中时调用JSBridge使用原生应用的交互能力，处于其他端例如小程序时使用三方生态提供的能力 —— 当无法最优解时，可以自动降级到兜底方案。

序言

近几年大多数常规应用都是采用MPA、SPA的方式，对每个路由绑定对应规则，达到匹配路由规则渲染组件的能力。

最近在开发一个聊天类应用，简称XX，经常使用微信、钉钉的应该体验过其状态和数据缓存的能力，e.g. 和好友聊天内容输入一半，其他应用弹出一条消息或由于某些情况中止剩余内容的输入，切出了和该好友的对话界面甚至切出了XX应用，待回到和该好友聊天界面内，之前输入的内容还在，可以继续输入。

这种体验放在原生应用上或许很常见，但移动端WEB少有聊天应用。不仅是web体验交互差，兼容成本也远超原生应用。web 数据持久化的难点是：

• 不具备完善的数据缓存机制，BOM API支持能力的差异与数据关系映射结构复杂不利管理。
• 低端机型浏览器易崩溃、用户刷新网页都会导致状态丢失。
• 路由机制，应用运行时一旦切路由上一个路由就失去了其最后状态和数据。
  Read more..

起因

前段时间紧急上线了一个门户项目，两端静态页面，首页考虑到需要极致体验必须使用硬编码搭建，部分子页面采用可视化搭建，要求Lighthouse必须接近满分，尽管通过一些手段优化了首屏但上线之后，离目标还有一大段偏差。

技术背景

表单域能力逻辑需要一层安全层过滤能力，预防传入的表单协议含有敏感数据或者调用原生能力造成 XSS 攻击。

技术目标

轻量体积，符合 eval 同步运算结果，可定制规则、过滤关键词、运算符，剔除冗余能力(原型链、Symbol、继承)，屏蔽原生能力，自成体系，定位是计算表达式且具备执行一定长度下符合脚本规则的能力。

前言

技术和架构方案不同，技术可以凭空出现突然爆火没有征兆。但方案或架构一定是为了解决某个问题而出现的，实践之前，请务必先要去搞清楚它是否可以解决当前问题，再者调研是否适合团队，考虑工程价值与产品价值，请不要盲目追求。

Serverless

定义

Serverless 至今还没有一个普遍公认权威的定义。正如新零售的概念，谁都在做但是谁也不敢认定它就是这样。按 AWS 官方对于 Serverless 的介绍：

本节是Hook专题，将从 preact 借鉴 Hook 的底层原理实现，虽然实际上 preact 与 react 的 实现有所差异，但是胜在简单，了解了解思路逻辑也是可以的嘛。

Suspense 与 lazy

在src/React.js里，有几个组件长得比较奇怪。

算是炒冷饭吧，最近看React源码发现有一些原型与继承方面的东西没看太明白，便计划花两天重温这方面的东西，以便之后有更好的脑回路。

写在前面

计划用半年的时间去深入 React 源码并记录下来，本文是系列文章第一章，前面大多数会以功能为主，不会涉及太多事务机制与流程，后半部分以架构、流程为主。这个是一个水到渠成的事情。看的越多，对其理解的广度就越大，深度也随之沉淀，在深入的同时站在作者的角度去思考，能够脱离源码照葫芦画瓢，才能算理解，读懂本身源码并不重要。可能没有什么休息时间，但是会尽量挤出来完善文章，也算是一种兴趣与习惯。