最近比較吐槽,大家都知道,現在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有這種方法。
ajax
這種方式很容易想到,但是你使用原生的xmlhttprequest的話,還需要考慮瀏覽器兼容,但不用原生的話,就要藉助於第三方框架,比如jquery,但是畢竟還是有很多公司是不使用jquery的,所以這個要根據實際的需要來使用了。
image
我們的dom中有一個叫做image的對象,所以可以透過動態給它的src賦值來達到請求後台url的目的,同時在url中加上我們需要傳遞title和message訊息,這種動態給image .src的方式是不需要考慮瀏覽器相容性的問題,非常不錯。
以上就是本文的主要內容了,後續我們將繼續深入探討