摘要：所以前端工程師不僅僅是寫好頁(yè)面和做好兼容性。對(duì)前端工程師的技術(shù)能力也會(huì)帶來(lái)考驗(yàn)。這里想要說(shuō)的是，如果使用了，使用了服務(wù)端渲染，對(duì)于前端工程師的個(gè)人素質(zhì)要求會(huì)比較高，因?yàn)樾枰幚砗芏喾?wù)端的問(wèn)題。

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

首先我們先看下下面我們項(xiàng)目中的幾個(gè)頁(yè)面，來(lái)總結(jié)下一些他們的特點(diǎn)。

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

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

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

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

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

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

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

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

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

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

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

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

{* 這里對(duì)某些組件做異步加載 *}

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

通過(guò)React-Router來(lái)做路由控制除了前端代碼之外，服務(wù)端也許呀做些配置。不然我們的頁(yè)面在回退的時(shí)候就會(huì)出現(xiàn)問(wèn)題（頁(yè)面找不到路由）。其實(shí)就是在我們通常說(shuō)的action成面做下路由控制，因?yàn)槲沂褂玫氖荖odejs，所以我的配置下面這樣子的。

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

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

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

import initReactFastclick from "react-fastclick";

initReactFastclick();

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

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

那么最佳實(shí)踐是什么呢？看下圖

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

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

舉個(gè)簡(jiǎn)單的例子，在整個(gè)項(xiàng)目中都會(huì)用到的彈窗組件：

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

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

    componentWillReceiveProps(nextProps) {
        
    }

    handleHideLayout = () => {
    }

    handleMobile = () => {
    }

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

    render() {

        return (
            

                
            
        );
    }
}

export default AlertForm;

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

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

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

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

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

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

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

這里想要說(shuō)的是，如果使用了Nodejs，使用了服務(wù)端渲染，對(duì)于前端工程師的個(gè)人素質(zhì)要求會(huì)比較高，因?yàn)樾枰幚砗芏喾?wù)端的問(wèn)題。前面也分享過(guò)一篇處理安全工單的問(wèn)題，不僅僅要面對(duì)服務(wù)端的問(wèn)題，還有面對(duì)來(lái)自互聯(lián)網(wǎng)安全的問(wèn)題。

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

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