--58安居客北京前端團隊《巧寓sass系統(tǒng)》開發(fā)紀實

前言

如標題所講，本文將要記錄的是我在真實的項目開發(fā)過程中，如何將一個2017年代碼的JQ項目一步步遷移升級為react + 微前端技術架構的。這個過程中，我們又經(jīng)歷了什么呢？踩過哪些坑呢？

項目介紹（站在巨人的肩膀上吐槽）

這是一個面向經(jīng)紀公司的sass系統(tǒng)，有PMS（經(jīng)紀人使用）和CMS（運營后臺使用）兩套系統(tǒng)，其在業(yè)務中的重要程度，不言而喻，本文不做過多的業(yè)務介紹，我們把側重點放在技術上。

原項目技術介紹

首先，這是一個jq + vue技術棧的項目，下面看一下原項目部分代碼截圖

看著這個用日期版本號，我猜測，這是一個17年甚至更早的項目，考慮到項目的體量，大概是在16年底的項目吧，那時候jquery確實是撐起來前端的一片天，不過也是在那個時候，前端技術圈正悄然著發(fā)生著翻天覆地的變化，ES6正在推廣普及，三大框架競爭激烈，webpack也悄然改變著前端工程化的面貌，babel的強大功能，也正在悄悄的滲透到前端的各個方面...
正當我為項目中有引入vue而慶幸時，接下里的一幕，卻又直接讓我流淚。

也就是說，如果有的頁面用到了vue，其用法就像是做demo一樣的，在html文件中引入vue.js然后像上面截圖那樣去掛載實例等等...當然，這也理解，因為在jq的大環(huán)境下（無編譯壓縮工具），vue也不可能做成單頁面應用這一類。我想可能這個項目就處在了當年前端技術變革的初期吧，開發(fā)者也是盡可能的想要去嘗試新鮮的技術。

再來看看項目架構，從表現(xiàn)上，整體的架構更像是一個SPA項目：有些統(tǒng)一固定不隨頁面刷新的布局，通過indel.html訪問項目...，但其實現(xiàn)原理其實是這樣的

• jquery已經(jīng)成為歷史，在現(xiàn)在的大環(huán)境下，開發(fā)者對于jquery的使用明顯的低效且bug率高
• iframe相互嵌套的代碼復用方式，對于邏輯的抽離和封裝并不是一個友好的方式，經(jīng)常會牽一發(fā)動全身，有時候不知道這個頁面被多少頁面所嵌套和處理。
• 現(xiàn)有的”偽SPA“模式，無法通過指定的url跳轉到對應頁面，原因就是上面截圖那樣的，重新加載index.html，只能到其初始化時的iframe頁面。
• 無前端工程化，編譯、打包、熱更新等概念...開發(fā)和部署起來十分難受
• 本地開發(fā)需依賴node或python服務，環(huán)境比較復雜
• 業(yè)務體量大，服務拆分不易，無法實現(xiàn)微前端等前沿技術
• 開發(fā)人員一直在老代碼中沒有技術成長
• ...

面對這諸多的原因，于是，我想，那做一個升級吧...

技術升級

如此大的項目，一次性重構必然是不可能的。這需要一步步的探索，一點點的蠶食，才能一步步踏入正軌。

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

通過上面分析，原有架構，在這個時代下存在著很大的問題，如果要升級，在原有的技術上迭代升級，幾乎是不可行的，那么首先就要先脫離原先的技術，創(chuàng)建一個工程化的、技術新的、正常的SPA項目。
新項目采用技術棧 react + antd + umi，第一個擺在我們面前的就是新老項目如何通信，首先要想接入老的技術架構，還是得讓我們新的SPA項目，成為老架構中上百html中的一個。這里就需要了解SPA的特點了

• 只有一個html
• 打包編譯后的JS和CSS（無關是否分包處理）當做靜態(tài)資源
• 因為SPA路由的存在，我們可以在SPA的index.html中通過指定url訪問對應頁面

既然SPA被當成了其中一個html,且通過URL訪問對應頁面，那么按照原有架構，我們也可以通過URL傳參的形式完成新老項目的數(shù)據(jù)通信了，實際上，原iframe架構中，所有的頁面之間的通信都是通過url傳參完成的，我們這樣也算是繼承了原有架構的特點。

第二步：SPA嵌入舊項目

通過第一步的操作后，其實是可以實現(xiàn)大部分完整的新需求的，但對于不太完整的重構需求來講，就會存在互相嵌套的過程，這也是當初解決的其中一個問題點所在，因為原項目中，有好多iframe互相操作的代碼，比如下面這樣的代碼：

第三步：面對弊端

我們通過上面的兩步，基本可以滿足所有的業(yè)務需求了，但隨之而來，帶來了交互上的一些弊端，因為是兩個獨立的項目，而新項目又為了保持環(huán)境的簡潔沒有引入太多復雜的東西，比如postmessage，所以，有一個問題就是，兩個想之間的方法調用問題，這是目前無法解決的，但是對于獨立模塊的重構，都是沒有問題的，對于新舊項目的混合，存在的交互問題，這里就只能讓我們的產(chǎn)品同學暫且妥協(xié)，等提出完整的需求可以將舊項目和老項目不嵌套后，那么我們的問題也就解決了。

第四步：微前端

通過上面一點點的對舊項目的“蠶食”以及時間的沉淀，我們的新需求已經(jīng)都可以順利的接入SPA項目了，并且已經(jīng)有幾個完整獨立的模塊完全脫離的老的架構，順著需求的增多，SPA的弊端也就暴露出來了，如首頁加載慢等，因為我們的SPA都是通過iframe的形式嵌入到老系統(tǒng)中的，終歸還是一個html，那么新開一個或者多個SPA已成必然，這也正是微前端的落地時機，我們將打算采用qiankun來做微前端的改造。

寫在后面

到現(xiàn)在為止，隨著時間和技術的沉淀，《巧寓Sass系統(tǒng)》已經(jīng)步入了一個開發(fā)正規(guī)，我們不斷的在尋找機會，解決問題，每到達一個時機，我們的項目升級就會進一步，相信不久的以后，本項目全部會被新技術替代。

總結一下：在開發(fā)中我們會面對各種棘手的問題，要善于思考，多多嘗試，當解決方案出現(xiàn)在眼前時，那一刻是多么的有成就感。并且自己也會在這個探索的過程中，有很大的收獲。