PWFD

怎么可能？！对啊，笔者一开始想的也是怎么可能。

今天我们来聊聊一个组件库怎么让开发用起来“爽”。

一个搭建Monorepo的时候都会遇到的问题

一个相信大家在写前端初期都会遇到的问题。我们来深入研究下~

你有想过类似ChatGPT的聊天客户端是怎么一个字个字地把大模型的回复返回回来的吗？

这期我们来讲讲能用babel的魔法干啥。。。

来聊聊前端原子化组件相关的问题吧。

剧本是这样子的，最近因为项目需要只能用一台Windows电脑作为开发机，但是本人的主力开发机是Mac。Windows的低压U性能比较羸弱，完全没法胜任跑调试服务器的任务。

于是乎决定让Mac和以前一样起开发服务器但是在Windows电脑上通过访问Mac的IP来访问调试服务器。
本来猜测可能的报错就是host没有设置成0.0.0.0或者Mac的防火墙阻断了入口。
试了一下主应用完美打开，但是子应用就是加载不出来，而且对子应用的网络请求一直处在Pending状态。

排查了半天最后发现问题出在我们对于qiankun的子应用entry的配置。我们主应用虽然配置的是0.0.0.0，但是给乾坤的所有子应用的entry全部都是配置的localhost，就等于是一台远程机器虽然通过内网IP访问到了远程的主应用，但是一直去本机找localhost，那当然找不到啊。

通过修改子应用的entry配置为远程机器的内网IP，问题解决。

但是还有一个问题，我们团队里面很多同学之前一直用的是云端开发，照理说不可能没有遇到过这个问题啊。。他们那里是怎么工作的？

调研了一下发现原来是VS Code的功能，VS Code在通过SSH打开远程目录并通过yarn start启动项目后，会把远程的端口映射到本地的localhost上面，这样虽然主应用访问的是localhost，但是因为localhost对应端口的子应用已经被VS Code从远程开发机上代理过来了，所以就能工作了。

具体VS Code远程开发怎么玩的可以直接看官方文档：Local Port Forwarding和 Remote Development using SSH

看了眼自己的博客都四个月没更新了，有点过分了，就写写前两天想到的一个主题吧。之前笔者做了一段时间Salesforce，平台上用来写前端组件的框架叫Lighting Web Component，简称LWC，顾名思义其实就是标准Web Component的一层封装。当时写的时候真是深恶痛绝，各种很神奇的问题，总结下来就是以下几点吧：

不支持TS

LWC本体是用TypeScript写的，但是用户在基于LWC编写组件的时候是没法使用TS的，只能使用标准的JS。导致项目维护起来特别困难，尤其是半路进去的项目，且遇到不规范的代码那是真的痛苦面具。

三方库支持有限

项目需要一个日历组件，日历嘛，懂的都懂，自己写估计是要累麻的，且一堆问题，但是开源社区早就有好的解决方案了。本来想的是我把JS和CSS引进来直接问题解决了，结果不行。当时猜测是因为Shadow DOM的原因导致的不工作，对，LWC每个组件都是跑在Shadow DOM里面的。

调试困难

普通前端开发，改完代码，秒级热更新直接看到效果；LWC开发，改完代码，把代码部署上云端（运气好大概几秒吧，运气不好几分钟），才能看到效果，效率天差地别。什么？你和我说有本地调试服务器？用过了，和在Org里面跑出来的效果都不一样。

缺少良好的状态管理和通信机制

状态全靠Class的props配合HTML attribute透传，官方有一套发布订阅模式的方案，但是极难维护，用起来比Redux还要繁琐，做个状态管理居然还要编写XML。

然后笔者最近因为项目原因微前端接触的比较多，用的微前端框架是qiankun，是基于single-spa的一层封装。也是遇到了一堆普通SPA完全遇不到的坑爹问题，也大概列一下：

样式冲突

假设主应用A有一个CSS Class名字叫a-b，子应用也有一个CSS名字叫a-b。子应用引入的时候就有可能导致主子应用的样式互相污染，比较好的方法就是CSS Module配合前缀来使用。

接入成本

虽然各种Demo已经相当完善了，但是接入的时候总有各种各样的问题。需要花费大量时间去排查，而且排查到最后发现可能就是一行配置的问题，有些坑没有踩过的话是真的不知道。

加载速度

微前端因为有特定的加载子应用的流程，所以做首屏加载优化非常困难。很可能是能做的都做了但是页面打开还是要至少2秒的时间，非常不可接受。而且现在似乎社区也没有比较好的优化方案，如果能配合SSR使用可能能解决一部分问题。

JS运行时冲突

主子应用如果修改了同一个对象，就有可能导致数据之前的冲突，比如说子应用要的东西被主应用干掉了或者反过来。不同子应用接入的时候可能还会导致local storage的冲突，非常抽象。开启沙盒只能解决一部分问题，比较靠谱的还是不同应用加前缀，但是这又给开发带来了成本。

哎？等等。。

读到这里有的读者应该已经能意识到了。。你刚说的微前端的这些问题，不就是LWC的架构设计已经解决的问题吗？之前吐槽的LWC开发时遇到的问题，不就是为了微前端工作良好吗？我们这个时候再来仔细复盘一下：

LWC所采用的Shadow DOM是浏览器原生支持的API，可以说是自带的一个“沙箱”机制，可以用来隔离DOM节点，CSS以及JS代码，可以很好地防止主子应用的互相污染。这也就解释了为什么对于三方库的支持不好，因为Salesforce的主应用其实就是平台本体，LWC是基于平台的二次开发，怎么可以因为二次开发导致平台本体的功能坏掉呢？这个是SaaS平台本体无法承受的风险。

同时因为底层是封装的浏览器原生支持的Web Component，加载的时候也不会带来额外的副作用，且也能保证加载的速度。没有太多的工具链其实也是为了保证架构层面的轻量级。基于平台的事件通信机制虽然带来了额外的编写XML的繁琐，但是能有效保证接入时的一致性。需要部署到平台才能看到效果一定程度上也保证了所见即所得，除非本地的调试服务器能完全模拟Salesforce平台的环境。

不支持TS某种程度上其实也是为了降低开发的学习成本，开发只需要会原生的HTML，JS以及CSS就可以基于Salesforce平台做二次开发。有利于社区的繁荣。

以上总结一下说白了就是，你只要用了我Salesforce的框架，在我限制的范围内写代码，我就能保证你的组件上生产的时候不出幺蛾子。这是个非常良好的做开放平台的思路，值得参考。

印象笔记最近广告越来越频繁了，用起来也不是很省心，而且印象笔记很多高阶功能我都用不到，我只需要单纯的记笔记和云同步两个功能，为了这每年付一笔钱不是很值。思考了一下选择拥抱开源–Joplin。