最近比較吐槽,大家都知道,現在web前端相對幾年前來說已經變得很重了,各種js框架,各種面對對象,而且項目多了,就會提取公共模塊。
這些模塊的UI展示都一樣,不一樣的就是后臺邏輯,舉個例子吧,我們做企業差旅的時候,通常都有一個成本中心的js公共模塊,客戶在預定機票的時候來填寫這個成本中心,而這種成本中心分布在online,offline和app等預定端,這樣也是方便后期和客戶公司進行月結算。
我們還知道,項目做大了,復雜化了,SOA化了之后,很多問題就來了,就像web中的一個理論,所有前端的數據都是不可信的,那對方團隊的接口數據又何嘗不是,以前項目小的時候,不會那么不自信,也只會在Logic error的時候會記錄下日志,正常的業務流程一般很少記錄,畢竟info日志看著不美觀,而且還會消耗服務器帶寬,也還會拖累web的性能。
但是項目大了,當你某天在項目中遇到了奇怪的bug時,你靠著殘缺不全的日志,好不容易用肉眼逐行追溯到了接口,但是參數太多,無法準確的還原接口的參數數據,但是你又100%的自信認定肯定就是接口的返回問題,但是又拿不出完整的報文,這時候你又沒法找接口提供方,當時那個無奈呀,多想最好每行都有日志該多好啊。
有了教訓后,記流程日志的趨勢越來越盛行,最終也釀造了一個年初的大事件,稀里糊涂的說了一大堆,web后端如此,那現在的重前端不也一樣要記錄日志么?我們知道既然是公共的js模塊,那這個模塊肯定自己封裝了一些方法,肯定是絕對不可以讓第三方程序去操作它自己的文本結點,比如下面這樣:
為了簡化操作,第三方UI提供了公司名和員工姓名的UI結點,并且封裝了一個costcenter類來提供讀取方法,可以看到,我的預定程序只需讀取costCenter.getInfo就好了,也起到了一個封裝的作用。
但是問題就出現在這里,項目實戰中會因為各種原因導致在costcenter中取不到值,當然也可能是common ui的bug。
但是當時你又不能非常確定是否真的取到了值,但是在邏輯上就算取不到值,原則上你也不能阻止訂單提交,所以為了徹底追蹤bug,就寫了個logCenter單例類來記錄日志。通常用js來記錄log有這種方法。
<1> ajax
這種方式很容易想到,但是你使用原生的xmlhttprequest的話,還需要考慮瀏覽器兼容,但不用原生的話,就要借助于第三方框架,比如jquery,但是畢竟還是有很多公司是不使用jquery的,所以這個要根據實際的需要來使用了。
<2>image
我們的dom中有一個叫做image的對象,所以可以通過動態給它的src賦值來達到請求后臺url的目的,同時在url中加上我們需要傳遞 title和message信息,這種動態給image.src的方式是不需要考慮瀏覽器兼容性的問題,非常不錯。
以上就是本文的主要內容了,后續我們將繼續深入探討
新聞熱點
疑難解答