从Jquery到React，从Iframe到微前端，我们经历了什么

--58安居客北京前端团队《巧寓sass系统》开发纪实

前言

如标题所讲，本文将要记录的是我在真实的项目开发过程中，如何将一个2017年代码的JQ项目一步步迁移升级为react + 微前端技术架构的。这个过程中，我们又经历了什么呢？踩过哪些坑呢？

项目介绍（站在巨人的肩膀上吐槽）

这是一个面向经纪公司的sass系统，有PMS（经纪人使用）和CMS（运营后台使用）两套系统，其在业务中的重要程度，不言而喻，本文不做过多的业务介绍，我们把侧重点放在技术上。

原项目技术介绍

首先，这是一个jq + vue技术栈的项目，下面看一下原项目部分代码截图

看着这个用日期版本号，我猜测，这是一个17年甚至更早的项目，考虑到项目的体量，大概是在16年底的项目吧，那时候jquery确实是撑起来前端的一片天，不过也是在那个时候，前端技术圈正悄然着发生着翻天覆地的变化，ES6正在推广普及，三大框架竞争激烈，webpack也悄然改变着前端工程化的面貌，babel的强大功能，也正在悄悄的渗透到前端的各个方面...
正当我为项目中有引入vue而庆幸时，接下里的一幕，却又直接让我流泪。

也就是说，如果有的页面用到了vue，其用法就像是做demo一样的，在html文件中引入vue.js然后像上面截图那样去挂载实例等等...当然，这也理解，因为在jq的大环境下（无编译压缩工具），vue也不可能做成单页面应用这一类。我想可能这个项目就处在了当年前端技术变革的初期吧，开发者也是尽可能的想要去尝试新鲜的技术。

再来看看项目架构，从表现上，整体的架构更像是一个SPA项目：有些统一固定不随页面刷新的布局，通过indel.html访问项目...，但其实现原理其实是这样的

是在index.html中加载一个iframe,通过菜单动态改变iframe的src来达到，类似单页面应用的效果。
其实，这个方案，确实在那个年代也是很优秀的设计，不得不说，前辈们的能力还是相当的强，但优秀的东西，可能随着时代变成历史，在我么开发的过程中，就出现了各种各样的问题

• jquery已经成为历史，在现在的大环境下，开发者对于jquery的使用明显的低效且bug率高
• iframe相互嵌套的代码复用方式，对于逻辑的抽离和封装并不是一个友好的方式，经常会牵一发动全身，有时候不知道这个页面被多少页面所嵌套和处理。
• 现有的”伪SPA“模式，无法通过指定的url跳转到对应页面，原因就是上面截图那样的，重新加载index.html，只能到其初始化时的iframe页面。
• 无前端工程化，编译、打包、热更新等概念...开发和部署起来十分难受
• 本地开发需依赖node或python服务，环境比较复杂
• 业务体量大，服务拆分不易，无法实现微前端等前沿技术
• 开发人员一直在老代码中没有技术成长
• ...

面对这诸多的原因，于是，我想，那做一个升级吧...

技术升级

如此大的项目，一次性重构必然是不可能的。这需要一步步的探索，一点点的蚕食，才能一步步踏入正轨。

第一步：接入正常的SPA项目

通过上面分析，原有架构，在这个时代下存在着很大的问题，如果要升级，在原有的技术上迭代升级，几乎是不可行的，那么首先就要先脱离原先的技术，创建一个工程化的、技术新的、正常的SPA项目。
新项目采用技术栈 react + antd + umi，第一个摆在我们面前的就是新老项目如何通信，首先要想接入老的技术架构，还是得让我们新的SPA项目，成为老架构中上百html中的一个。这里就需要了解SPA的特点了

• 只有一个html
• 打包编译后的JS和CSS（无关是否分包处理）当做静态资源
• 因为SPA路由的存在，我们可以在SPA的index.html中通过指定url访问对应页面

既然SPA被当成了其中一个html,且通过URL访问对应页面，那么按照原有架构，我们也可以通过URL传参的形式完成新老项目的数据通信了，实际上，原iframe架构中，所有的页面之间的通信都是通过url传参完成的，我们这样也算是继承了原有架构的特点。

第二步：SPA嵌入旧项目

通过第一步的操作后，其实是可以实现大部分完整的新需求的，但对于不太完整的重构需求来讲，就会存在互相嵌套的过程，这也是当初解决的其中一个问题点所在，因为原项目中，有好多iframe互相操作的代码，比如下面这样的代码：

通过contentWindow这样的方法去做两个iframe之间的方法调用，这样一来，如果我们的SPA用SPA嵌套了旧项目的页面，就会导致一些跨域问题（DOM操作跨域），对于这样的问题，本地开发，因为新旧项目不同端口，确实无法解决，也只能在两个项目部署在一起后自然而然的解决了。不过，这里就体现了”蚕食“的重要性了，随着重构的需求越来越多，互相嵌套的场景也会越来越少，那么这样的问题就自然而然解决了。

第三步：面对弊端

我们通过上面的两步，基本可以满足所有的业务需求了，但随之而来，带来了交互上的一些弊端，因为是两个独立的项目，而新项目又为了保持环境的简洁没有引入太多复杂的东西，比如postmessage，所以，有一个问题就是，两个想之间的方法调用问题，这是目前无法解决的，但是对于独立模块的重构，都是没有问题的，对于新旧项目的混合，存在的交互问题，这里就只能让我们的产品同学暂且妥协，等提出完整的需求可以将旧项目和老项目不嵌套后，那么我们的问题也就解决了。

第四步：微前端

通过上面一点点的对旧项目的“蚕食”以及时间的沉淀，我们的新需求已经都可以顺利的接入SPA项目了，并且已经有几个完整独立的模块完全脱离的老的架构，顺着需求的增多，SPA的弊端也就暴露出来了，如首页加载慢等，因为我们的SPA都是通过iframe的形式嵌入到老系统中的，终归还是一个html，那么新开一个或者多个SPA已成必然，这也正是微前端的落地时机，我们将打算采用qiankun来做微前端的改造。

写在后面

到现在为止，随着时间和技术的沉淀，《巧寓Sass系统》已经步入了一个开发正规，我们不断的在寻找机会，解决问题，每到达一个时机，我们的项目升级就会进一步，相信不久的以后，本项目全部会被新技术替代。

总结一下：在开发中我们会面对各种棘手的问题，要善于思考，多多尝试，当解决方案出现在眼前时，那一刻是多么的有成就感。并且自己也会在这个探索的过程中，有很大的收获。