摘要：所以前端工程師不僅僅是寫好頁面和做好兼容性。對前端工程師的技術(shù)能力也會帶來考驗。這里想要說的是，如果使用了，使用了服務(wù)端渲染，對于前端工程師的個人素質(zhì)要求會比較高，因為需要處理很多服務(wù)端的問題。

我們團隊有個項目由于開發(fā)時間較長，且是前后端雜糅的開發(fā)方式，維護成本很高，在線上暴露的問題很多。而且因為對接了公司一百多條產(chǎn)品線，每天都會接到大量的客訴和產(chǎn)品線反饋的問題。2017年11月份以產(chǎn)品為主導(dǎo)，從產(chǎn)品層面對流程進行重新設(shè)計，對該項目進行了前后端的重構(gòu)。作為前端的負(fù)責(zé)人我用這篇文章分享下，整個過程從技術(shù)選型，開發(fā)，上線的一些經(jīng)驗。

首先我們先看下下面我們項目中的幾個頁面，來總結(jié)下一些他們的特點。

我們的頁面主要是需要用戶填寫的表單居多，在頁面加載的時候不需要去請求獲取和渲染大量的數(shù)據(jù)。而且一個頁面需要顯示的狀態(tài)較多（比如上面的3張圖，在項目中是一個組件）。還有一個最主要的業(yè)務(wù)需求，百度公司內(nèi)部產(chǎn)品線較多，不同的業(yè)務(wù)都有其獨特的賬號標(biāo)簽，這些賬號除了會走一些通用流程還要走一些對應(yīng)產(chǎn)品線特色的流程。

結(jié)合這些業(yè)務(wù)特色和之前有Nodejs和React的開發(fā)經(jīng)驗，我整體的一個技術(shù)選型是FIS3+Nodejs+React+Redux+React-Router。那么這些技術(shù)選型能帶來什么呢？

前端可以在瀏覽器端控制頁面跳轉(zhuǎn)的路由，增加了前端開發(fā)的靈活性；

頁面可以根據(jù)業(yè)務(wù)需求在服務(wù)選擇模板引擎渲染或者是同構(gòu)渲染；

前端對錯誤碼文案和頁面文案做統(tǒng)一的管理，而且通過Nodejs來實現(xiàn)線下“熱更新”他們，線上實時生效；

有了Redux之后，做跨組件（多頁面）的數(shù)據(jù)共享更加方便。減少無意義的網(wǎng)絡(luò)請求。提高項目運行的穩(wěn)定性和可用性。

這里簡單的聊下工程化工具的選擇。目前在業(yè)內(nèi)最火的工程化工具就是Webpack了吧。除了看過文檔之外，并沒有太多的實際應(yīng)用經(jīng)驗。我一直認(rèn)為使用工具就是來幫助開發(fā)者解決一些開發(fā)過程中遇到的一些需要人為頻繁去操作的無異議的工作。拋開Webpack我們依舊可以手動去編譯代碼，手動部署，手動刷新頁面來開發(fā)，使用工具只是讓這一系列的流程能夠連貫起來，降低開發(fā)成本。

在我的所有跟公司有關(guān)的項目中選擇的都是FIS3，我也認(rèn)為他足夠的好用，能滿足我各色各樣的工程化需求。我并不是排斥Webpack。我只是還沒有找到一個理由，讓我選擇放棄現(xiàn)在使用的FIS3去使用Webpack。

這里簡單介紹下，決定了技術(shù)選型之后，對于渲染頁面渲染機制的一些區(qū)別。

之前舊項目使用PHP+Smarty的渲染模式，將頁面在服務(wù)端渲染完成之后再統(tǒng)一吐給前端瀏覽器。而使用新的技術(shù)架構(gòu)之后，我們渲染頁面的方式更加的靈活?？梢赃x擇在服務(wù)端渲染，可以完全交給瀏覽器渲染，可以同構(gòu)渲染。因為我們的頁面在首屏的時候不需要加載大量的數(shù)據(jù)，所以我還是讓大部分頁面在瀏覽器端進行渲染。

還有一種區(qū)別就是之前所有來自用戶的請求都會落到PHP的服務(wù)器上去。而新框架的請求都會落到前端的Nodejs服務(wù)器上去。所以前端工程師不僅僅是寫好頁面和做好兼容性。對前端工程師的技術(shù)能力也會帶來考驗。

前面談的技術(shù)選型已經(jīng)提到了使用React-Router來做頁面路由控制。而且React-Router提供了異步加載組件的功能，這為我們上線優(yōu)化頁面的異步加載提供了技術(shù)基礎(chǔ)。

{* 這里對某些組件做異步加載 *}

        
function selectUser() {
    return (location, cb) => {
            require(["../accountselect/container/AccountSelect"], function (component) {
                cb(null, component);
            });
        };
    }

通過React-Router來做路由控制除了前端代碼之外，服務(wù)端也許呀做些配置。不然我們的頁面在回退的時候就會出現(xiàn)問題（頁面找不到路由）。其實就是在我們通常說的action成面做下路由控制，因為我使用的是Nodejs，所以我的配置下面這樣子的。

router.get("/fillname", router.action("index"));
router.get("/selectuser", router.action("index"));

在前端事件因為開源協(xié)議的問題曾經(jīng)短暫使用過Preact。React和Preact最大的區(qū)別就是對于一些事件的封裝。這些造成了Preact相對于React體積小很多。
做移動端開發(fā)，前端經(jīng)常會面臨的一個問題就是click事件 300ms 延時的問題。在React中提供的onClick事件同樣也會出現(xiàn)這樣的問題。如果如果我們想要在點擊一個按鈕之后，在其它地方立即出現(xiàn)反饋，最好就是使用onTouchEnd事件，或者就是使用開源的Npm包react-fastclick能很好的解決click事件 300ms延時的問題。

使用的方法就是在我們代碼的入口地方，聲明以下語句，他默認(rèn)會改變react的onClick事件的行為

import initReactFastclick from "react-fastclick";

initReactFastclick();

在使用React的時候可能都會面臨的問題，我的組件應(yīng)該是無狀態(tài)的還是有狀態(tài)的。我的組件狀態(tài)怎么共享。什么時候我應(yīng)該使用Redux來管理組件的狀態(tài)。剛開始接觸react都會有這樣的疑問吧。

一種比較極端的做法就是，不管狀態(tài)需不需要共享，組件的所有狀態(tài)都試用Redux來管理。這樣的做法就是我們需要寫大量的Action。如果是一兩個頁面還好，如果是十幾個頁面，真的寫action是能把人寫崩潰的。

那么最佳實踐是什么呢？看下圖

當(dāng)我們要寫一個組件的時候，首先想下這個組件是不是需要與其它組件共享它本身的狀態(tài)。如果需要我們應(yīng)該把它當(dāng)做有狀態(tài)的組件來設(shè)計，而且共享的狀態(tài)使用Redux來管理。如果簡單的就是無狀態(tài)組件或者是這個組件本身的狀態(tài)改變不會影響其它的組件，就可以將組件設(shè)計為無狀態(tài)組件（雖然叫無狀態(tài)組件，其實組件本身的狀態(tài)也是可以使用this.state來管理的）。

React的一大熱點就是組件化的開發(fā)思想。小到頁面上的一個按鈕都是可以設(shè)計成一個組件。既然是組件我們首先就應(yīng)該考慮這個組件怎么被其它組件復(fù)用。

舉個簡單的例子，在整個項目中都會用到的彈窗組件：

class AlertForm extends Component {
    constructor(props) {
        super(props);

        this.state = {
            showlayout: false,  // false 以tip的方式提示錯誤， true以彈層的方式提示錯誤
            btnlist: false,
            formbtn: false
        };
    }

    componentWillReceiveProps(nextProps) {
        
    }

    handleHideLayout = () => {
    }

    handleMobile = () => {
    }

    handleChangeCheck = () => {
        history.go(-1);
    }

    render() {

        return (
            

                
            
        );
    }
}

export default AlertForm;

我們將這種可能在其他頁面都用的組件多帶帶抽象成出來，在需要用的地方import。

import AlertForm from "../../components/AlertForm";

完成項目之后肯定要做的一項工作就是上下前的優(yōu)化，上線前我做的工作主要如下：

前面已經(jīng)談到錯對于大多數(shù)用戶來說都只是會走一些普通流程。有些具有產(chǎn)品線特色的用戶會走一些特殊流程。所以在上線前肯定要拆包，和做組件的異步加載。具體的前面已經(jīng)提到過了。在打包的時候?qū)@些頁面的js需要使用打包工具做多帶帶的處理。

其實除了這些需要異步加載的頁面之外還會存在一些其他自己編寫的lib庫（自己編寫的小函數(shù)）。還有比如全國省市地區(qū)對應(yīng)關(guān)系，電話區(qū)號對應(yīng)關(guān)系。因為這些函數(shù)或者是地區(qū)關(guān)系映射圖在上線以后基本上都是不會再變化的，所以與業(yè)務(wù)的js分開打包。

我們的打包的配置文件如下：

前面已經(jīng)談到使用Nodejs做中間層，做路由控制和服務(wù)端渲染。下面的這張圖是我寫這篇文章的時候截取的額以上服務(wù)實時狀態(tài)圖。可以發(fā)現(xiàn)，整個應(yīng)用對于內(nèi)存、磁盤IO利用率還是很正常的，對于CPU的利用率有點兒高，這也是后續(xù)需要優(yōu)化的地方。

這里想要說的是，如果使用了Nodejs，使用了服務(wù)端渲染，對于前端工程師的個人素質(zhì)要求會比較高，因為需要處理很多服務(wù)端的問題。前面也分享過一篇處理安全工單的問題，不僅僅要面對服務(wù)端的問題，還有面對來自互聯(lián)網(wǎng)安全的問題。

使用Nodejs除了來做服務(wù)端渲染。我還在使用Nodejs做了一些其它的工作。

比如我在服務(wù)端使用Nodejs管理了這樣一個JSON文件。PHP端不在維護錯誤碼和錯誤碼顯示的文案。所有前端需要顯示文案放在Nodejs端做統(tǒng)一的管理。而且，我線下也可以同通過系統(tǒng)對這些錯誤文案進行動態(tài)的更新。提高系統(tǒng)的可用性。