如果以微前端的视角看LWC。。

看了眼自己的博客都四个月没更新了，有点过分了，就写写前两天想到的一个主题吧。之前笔者做了一段时间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的框架，在我限制的范围内写代码，我就能保证你的组件上生产的时候不出幺蛾子。这是个非常良好的做开放平台的思路，值得参考。