使用React构建多端容器

序言

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

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

数据管控路由实现状态持久化

序言

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

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

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

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

Lighthouse 流程架构

起因

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

实现简版eval

技术背景

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

技术目标

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

微前端时代思考与实践

前言

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

为什么ServerLess

Serverless

定义

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

React传-3

alt=poster

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

React传-2

alt=poster

Suspense 与 lazy

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

重学原型与继承

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

React传-1

alt=poster

写在前面

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